2

Background Having run through the Getting started with API Apps and ASP.NET in Azure App Service tutorial (https://azure.microsoft.com/en-gb/documentation/articles/app-service-api-dotnet-get-started/), we had an architecture question arise today around the design decisions made to split out the To Do List Application API layers into a Middle tier API app and Data tier API app.

ToDoListApplicationArchitecture

When approaching build of an application using a distributed architecture, what considerations should take place to understand when this type of separation should occur in your API layers?

Another way of asking this question is what are the pros and cons of having a separate middle tier API layer and data tier API app when building your application?

Other Questions I had a read of Web apps architecture: 1 or n API question (see link that follows) which while being insightful, was slightly different to the question we are asking. We are talking a single domain which has separate API layers for middle tier (logic) and the data tier.

Web apps architecture: 1 or n API

Community
  • 1
  • 1
Arnie
  • 33
  • 3

2 Answers2

1

This of course, depends. Deciding whether to build out what I call "infrastructure services" is very strongly dependent on your needs and your application(s).

Infrastructure tier services generally get much more re-use than business logic tier services. They are very easy to recompose into new applications. The most common instance of this is building an admin interface as a separate application.

If you have already build several applications in your organization, and have found reuse to be occurring regularly, then I would seriously contemplate infrastructure services. If your organization is writing it's first application, and you don't see this fanning out to additional interfaces, then maybe just isolate your data access in a DAO pattern, it's fairly straightforward to refactor it out to a stand-alone service later.

Rob Conklin
  • 8,806
  • 1
  • 19
  • 23
  • Thanks for the explanation Rob, that is exactly what I was looking for. In the specific scenario we were looking at I can see now that we would not realise the benefits of using an infrastructure service in the forseeable future - so a single API layer with a DAO pattern would be the way to go for us. Thanks again! – Arnie May 20 '16 at 13:29
0

I think the example design is somewhat confusing. In real world, I have not seen such design yet because design looks like having every function to be http/rpc call?

My experience would be the SPA uses a Public API (or Gateway API) which then calls your Internal API / Microservices to aggregate results. It is your Microservices that may have DAOs and, most importantly, the business logic

Eric Huang
  • 49
  • 4