0

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?

1

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.

  • SOA is an outmoded term. It is associated with service buses, complexity, scaling problems and metadata difficulties. While some elements of SOA still survive, modern software systems favor microservices and simpler architectures. The term "middleware" is very vague; Wikipedia defines it as "anything between the user application and the OS kernel." – Robert Harvey Nov 26 '16 at 16:37
  • Totally agree. That's why I introduced the description as vague. The example introduce a system formed by components (or services) but I didn't dare to call them Microservices, that's why I used SOA instead as a more genric term to approach OP to the concept of systems based on services. I will look for a better example of middleware and I will change the link. – Laiv Nov 26 '16 at 16:59
  • @RobertHarvey I have read again the Wikipedia definition and I have to admit that it put too much emphasis on the fact that middleware is a midtier in between apps and the SO. However the way I'm refering the term is probably close to the one introduced under the title "Middleware in distributed applications", where the application (in this case) is not the API app, It's the app made in Angular (the client) or Android/iOS (also the client). – Laiv Nov 26 '16 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.