My microservice prototype currently has a Spring boot MVC application as its front-end. The application renders the View completely in the backend. It makes rest calls to other microservices like OrderService or ShippingService that are behind an API Gateway. Scaling the micro-services behind the API Gateway is no problem. But scaling the front-end MVC with a session is not that great I guess. I can implement Oauth2 and I could set the fronted also stateless!?

I often see microservice architecture examples with a complete JavaScript fronted like Angular. Is it normal to use that with a JavaScript client in the browser? When should I use server side rendering and when the client side renders with JavaScript?

Why I want to use server side rendering: I want to make all the microservices a self-contained system. Every service like a ShippingService(Resource) and the OrderService(Resource) have their own Spring MVC server side front-end (delivering the side and some JavaScript for back-end calls only related to that service). When the OrderSerivce goes down, for example, the Shipping service is still completely usable. Just the links to the OderService are not included because the service is not available.

Otherwise, when I use a web portal (Spring MVC application) that delivers the user the JavaScript client it would have the same behavior but what if the web portal goes down?

What about all the JavaScript code that is related to all the different microservices? There would always be a strong dependency or not?

I would also like to know if it is better instead of adding a Spring boot MVC app to each microservice if I just add the HTML to the OrderService and provide a link. When the user clicks it the browser will show the HTML page rendered by the OrderSerice instead of having a REST API?

  • 4
    Pure client side is in vogue right now, but there's nothing wrong with a server side front-end if your UI is fairly simple. It's easier to write and maintain. Adding a purely client side front-end like you get with Angular would basically give you two codebases per microservice, a server side codebase and a client side one, which means extra complexity.
    – Torisuda
    Commented Mar 4, 2017 at 1:11

1 Answer 1


From an architectural perspective, I wouldn't be worried about the technology that you use for the view. I prefer to use an angular-like framework for the frontend but both, Spring MVC and a client-side solution, can accomplish there purpose.

However, create something stateless is a must in order to scale properly. Besides, every request from the client should pass through the API gateway (best place to handle things like authentication).

I would also like to know if it is better instead of adding a Spring boot MVC app to each microservice [...]

About that, I would say that you could develop one view for each microservice only if you can assure that your client won't talk to another microservices. In another case, you should probably create a single view.

Hope this helps you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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