We currently have a work stream where we are splitting out a Monolith into microservices and there has been a debate as to how we will access and persist data.

To give you a good idea of how most of our apps are being set up, we have an app built strictly for the UI, a Web API it talks to and then another Web API that, that API talks to that manages access to the database.

While it definitely seems appealing to have a Web API that we use to manage access to the database, we still have to build out endpoints specific to each app and, for the most part, the Web API our UI App talks to just acts as a proxy.

Also, there is no real design pattern set forth, do we just use our Web API as a proxy, or do we set up multiple end points in the data layer API and consume all of those to create our own DTOs?

This is a C# project and we typically use Entity Framework, so to me it seems like using a Database First approach to generate our Entities in our Web Api makes a lot more sense. That way we aren’t managing migrations in multiple projects.

It seems too late in the game to separate our database into multiple databases, which is something I would prefer.