I'm a software developer, and the kind of developer we call "front end developer". I'm working on stuff like Angular, React, Vuejs and many others.

I wanted to know how we can organize our front end code so that we can fit a microservice architecture.

Actually, we scale services across units, each service is "independent" or at least, is decoupled from the others. This makes perfect sense. My question is:

How can we organize code, so that our front end code can matches these services?

I don't want to build monolithic applications in a microservice and big scale context. I was thinking of a way to split my front end components. But the problems come when we try to expose those components in a webpage that would aggregate them to build a real application...

I'm a bit lost in this situation and I need some help understanding the flow on a front end side.

If you can, please link any articles, or practices that could help me.

3 Answers 3


The last week or so I've been exhaustively researching the idea of microservice organization on the FrontEnd.

I think the easiest approach would be to leverage your library/framework of choice to separate different pieces of the Front End in verticals that correspond to the respective backend micro services. In Angular that would be something like Modules that are lazy loaded where each module corresponds to a microservice. You could go so far as to use your build tooling (ie. Webpack) to limit the output to just the components for the micro service(s) being deployed.

If you already have discrete front end repositories then it's more challenging because you have to decide how to stitch together the components. Some options for page composition include:

  • HTML iframes which have been around for a long time, but have trade-offs such as performance, communication between components, nesting of components, etc. However iframes offer the most freedom when it comes to allowing two (micro service) components to run side-by-side in the same DOM.
  • Polymer, Vue and React offer a lot when it comes to composition of custom elements but without a different root document you'll have to carefully manage component dependencies so libraries aren't fighting/breaking each other.
  • native web components are eventually coming to modern browsers but you'd be better off using Polymer, Vue or React as I believe they offer polyfills and other advantages.

Since I can only post 2 links, here are perhaps the most relevant.


I am not much of a microservice proponent (somewhat indifferent to the concept), having said that when using them I would still consider hiding them as much as possible from the frontend using a 'backend for frontend' (BFF) specific API. Microservices should be swappable, this swapability doesn't improve when you take dependency on them from your front-end.

Say you have a 'microservice' that deals with sending templated emails for you. Your front-end calls your BFF API, requesting sending of an email. The BFF will appropriately pick and invoke the microservice on your behave. Keep your front-end agnostic.

  • Maybe my question is not really clear, I m not asking how to call a remote gateway to access hidden services. My question was more about code organisation. If we admit that a services provides an information, it would be interesting to give a representation at a web / module format. I don't know if it exists or not, but this was my question. However, thank you for the response
    – mfrachet
    Commented Jan 27, 2017 at 7:54
  • 1
    @margin I think the concept of microservices doesn't translate that well to front-ends, maybe you are overthinking this a bit too much. Just look at regular modularization to organize your code. If you end up aggregating every component together it's still a monolith..
    – Joppe
    Commented Jan 27, 2017 at 9:04

In the company I work at we have a lot of microservices. I do not know much about web development but our Android and ios apps have a structure that mirrors the microservices. So there is a CustomerApi class which only handles network to the CustomerService (in the backend) and then in the apps there is also a CustomerService class which holds the public methods that other components in the app can use like getCustomer() or updateCustomerPaymentMethod(). These service classes are then injected in the other app classes for use. We actually had this architecture in the apps even when we still had a monolithic backend and it was a very natural way to organize responsibilities.

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