Microservices: How to integrate the UI? [closed]

Question

today I started reading about Microservice architectures - and it seems to be very interesting! But I have one doubt I need some explanation on: Assume I want to create a blog and would build 4 microservices for that: User/login Service, Article Service, Comments Service and Reporting/analytics Service(not a realistic example, I know...). The Reporting/Analytics service is purely backend - no issue here for my understanding. But the three others involve some UI part - and as to my understanding this UI part should also be part of the microservice itself, right? How would the UI integration work? Would I then have a 5th "front door" service that collects the user requests, forwards them to the other services which then answer with HTML/CSS and the front door service would then compose the individual responses into what is returned to the user?

Any chance, you have an example/use case for such a scenario?

Thanks and regards!

Answer 1

From my experience, in a microservices architecture, it is often useful to have a service that acts like an API gateway that front loads to the more domain specific microservices that does the work. The responsibility of the API gateway could be to aggregate results and return them to the front end but consolidating responses that are returned from the microservices would be coupling the knowledge of the two services and leaking some domain knowledge into the API gateway layer. The API gateway should probably be as thin as possible and should reach out to services to accomplish something.

The use case here that you're describing would be trying to authenticate the user before reaching out to the login service and then the article or comments service. Altogether the front end would still stay monolithic if they are a part of the same application.

If the application becomes big enough, the application would be separated by products but probably still rely on a core set of services. In that case, they would probably live in different UIs so that would make it less complex (kind of like microservices on the back end). Just as a side note, that a microservices architecture usually introduces a set of core services that can be utilized by different teams and therefore different applications that have different UIs. An example being an ecommerce application, that has customer service department editing orders for servicing customers and customers using an orders service to make purchases. In effect, these are two applications and they will have two different UIs. Hope this helps!

The other thing that I'd like to point out is that a microservices architecture is only great when the application becomes too large and complex. A microservices architecture requires more resources as it has some additional overhead. Start with a monolithic first :).

Answer 2

There are a couple of different approaches that you can take. If it makes sense each microservice can have its own pages that it can render. Then you only need a front end that can create the appropriate navigation for the involved services. The menu is built for the application, each service presents its own UI. This approach works well when you need to have the ability to include or exclude services from the application, for instance, based on licensing.

Alternately, each microservice can provide a set of HTML Fragments. Then you need a front end service to compose the pages and navigation. The fragments must all use the same vocabulary for CSS or whatever means you use to define the look and feel. This approach can lead to odd pages when HTML fragments are composed without one or more service that might be included.

Finally, a complete application UI can be built on top of the microservices. This can result in a "tighter" UI with a better flow. It also will typically take longer and be more difficult to change as new services are added.

What is the best? As with most cases in software development, it depends on what you are building. In the case of the Blog application, you described I suspect that each service could have its one full page UI. More commonly having a full UI is the approach I have seen. The HTML Fragment approach is more versatile but takes longer to develop initially. Once it is built though you will have more flexibility in how you deploy your application. This could be a real benefit for a Software Product company.

Hope that helps.