I was checking out the App Service on Azure and in one of the tutorials two API apps are created, one for data and one to be accessed by external apps. It's not clear to me from the tutorial what the real benefit is to having this separation. Since I'm assuming all the Data API is intended to do is talk to a database, why not just connect the DB directly to the API app your external apps are going to be using? Can someone tell me what I'm missing here?
Why use an intermediate API in this Azure App Service setup?
architecture;api design;azure
It's named separation of concerns. The example takes the principle beyone the scope of the classes and objects.A vague description of the components could be:Data API is meant to be what we know as DAO. API app is where the domain model and the business runs at (or part of it), and it's exposed via API web.These kind of apps might integrate more servicies. That's why they are known as middleware.The given example illustrate the sort of architecture it's expect to be deployed in the cloud. Microservices.Maybe, the example is too simple and both components (APIs) seem to do the very same thing, but the differences lie on their respective responsabilities (as part of a whole).why not just connect the DB directly to the API app your external apps  are going to be using?You could indeed. It's up to you. It's your needs, your requirements, your design. In  the case of the example doesn't matter. The system is very simple.However, in more complex systems, you may suffer what we know as coupling. Not the one between classes. The one between apps/services.The example is trying to be as simple, complete and suitable to the context (cloud) as possible.