Architecture of a microservice based web app

Question

I am confused about the point at which a web application diverges into microservices - is it at url level or models level? As an example, Suppose I have a monolithic app that serves 3 pages. Say each page serves a separate usecase and I want to back each of them with their own microservices. Now, which of these is the correct way of implementing a microservice based architecture:

• I create three different apps(microservices), each containing the (route, controller, models, templates) for one of the pages. And then based on which ever page is requested, I route the request to that particular app. This means that the whole page from database to HTML is served by a separate app. Basically, different pages in the same website are being completely served by different apps on the backend.
• The 3 microservices do not handle the UI stuff but only the data for their usecases(models, controller, no templates) and expose it over a REST api. I have one public facing app. This app queries the three different apps(microservices) only for the data and then builds the html pages to be returned to browser. All the pages in a web app in this case are being served by a single app which internally makes use of three different microservices.

Answer 1

As usual in Software Engineering, the answer is it depends. I can't imagine a reason right now but the option 1 could be useful in some particular scenarios.

However, considering the formal definition of microservices, the option 2 illustrates it better. One of the main advantages of having microservices is being able to reuse it. Different applications have different requirements and needs on presenting the information. Making your microservices return a JSON representation of your data will give you more flexibility on how to format this information.

Answer 2

You trouble is how model your microservices.

In term of microservices the second approach is most appropriate, which expose its logic through API.

Always when you model your microservices keep in mind the follow facts.

• Loose Coupling: When services are loosely coupled, a change to one service should not require a change to another. The whole point of this Microservice thing is being able to make a change to one service, and deploy it, independent of a need to change any other part of the system. This is really quite important.

• Strong Cohesion: We want related behaviour to sit together, and unrelated behaviour to sit elsewhere. Why? Well, if we want to change behaviour, we want to be able to change it in one place, and release that change as soon as possible.

Answer 3

Api gateway pattern of Microservice apigateway is the first point from where you can start distributing or forwarding the calls to different services

Answer 4

We're currently implementing an architecture similar to your second option. We encountered the following complexities while doing it: (feel free for anyone to chime in to this as it's still a work in progress)

• There is still technically a monolithic app in your system (the user facing app). Each time a change is done in the REST api you'd have to change the front facing app to handle those new changes. Don't even get me started on how you introduce a new microservice behind it. So in essence, the more microservices you put behind it, the bigger that API Gateway gets. (https://www.nginx.com/blog/building-microservices-using-an-api-gateway/)

The API Gateway also has some drawbacks. It is yet another highly available component that must be developed, deployed, and managed. There is also a risk that the API Gateway becomes a development bottleneck. Developers must update the API Gateway in order to expose each microservice’s endpoints. It is important that the process for updating the API Gateway be as lightweight as possible. Otherwise, developers will be forced to wait in line in order to update the gateway. Despite these drawbacks, however, for most real‑world applications it makes sense to use an API Gateway.

• For re-usability I designed an abstraction layer that defines unique behavior for communicating with each microservice. One concrete implementation for each microservice. This introduced another layer of complexity because now we had to maintain what we called "RPC connectors" along with its corresponding microservice. Personally, this ate a lot of a developer's time since, on top of maintaining their respective microservice they had to maintain the connector. If any of those were out of date, the public app would fail. Also, changes in the connector would require a public app rebuild (we currently defined the connectors as jar dependencies).
• While this is mentioned in another post and a blog, the foreign key relationship becomes a mess when dealing with multiple microservices handling its own db. (Database per service pattern) Your front facing app is now facing the problem of having to stitch them together. ("I need this data but I have to look up these keys to in each microservice to see who has what.") I'm not saying this is the right way to do it but if we're dealing with multiple rows returned then each of the ids have to be individually resolved from a microservice. I'm not sure how efficient this is though. I would be glad to hear suggestions.