markdown guide

Turns out that a decent definition of Micro-frontends just got published on Martin Fowler's blog.

I architected a fairly massive system that would be called a "Micro-frontend" today back in 2014. The design I came up with was based conceptually on Microservices, as UI components all communicated via event queues, so I think "Micro Frontends" ends up being a good name to choose for that style of architecture.

The specific design I chose was triggered by the following constraints:

  1. I finally had a Frontend Component system that was good at what it did (ReactJS). Without a real component system, IMO, you can't even begin to approach Microfrontends.

  2. I had dozens of disparate teams scattered throughout a multi-national enterprise each of which had dev teams who would never have the opportunity to collaborate even if they wanted to...and they typically didn't want to.

  3. The executive mandate was to create a cohesive UI that to our customers looked seamless with contributions from all of these dozens of teams.

  4. Contributions from the various teams had to be able to be combined in ways such that the whole would be greater than the sum of the parts, i.e., it was more valuable to the user to use 5 components developed by 5 teams in the same UI than if you were to use each of those team's UIs on their own.

  5. The backend APIs were developed by yet other development teams and were most often completely decoupled from the UI that used them.

Outside of these styles of constraints, I am not sure why anyone would choose a Micro-frontend architecture, as the cost of having the required level of decoupling is a waste unless you need that decoupling.

Here's my take on the main pro and con of a Micro-frontend vs. a UI that is well-built with cohesive components.

  • Microfrontend Pro: Anyone at any time can pick any part of UI and enhance or replace it with no fear of breaking anyone else's piece of the UI.

  • Microfrontend Con: It is necessarily more complex than having a well-built component system, and will tend to require more ceremony around the creation of components that you would have otherwise.

FWIW, I've built 3 other non-trivial frontends since finishing the Micro-frontend one, and I haven't used a micro-frontend architecture since, as it was overkill for the problems I was solving.


Very interesting, I have heard that MicroFEs has a lot of overhead and quite a few people were against it.

To me, if a component library was built in a good way, then you would be able to extend a single component without worrying too much about breaking everything. That obviously depends on the complexity of the component. (I might have too many expectations from a component library though)

Thanks for the very detailed reply!


In addition to the Neil Green comment. Micro-frontends is also an approach for strangling a monolith application or evolving it using a strangler pattern. FE technologies evolve very fast and MFEs enabling steadily migrating an application.

I wrote some months ago how to strangle a PHP application to making it server-side and client-side render views using Vue.js.

True true, instead of refactoring the whole app, you start by converting small components until the whole app is converted. Definitely a good use for MFEs.

Classic DEV Post from May 21

Ten Cognitive Biases to Look Out For as a Developer

Cognitive biases can be viewed as bugs in our thinking. In this blog post we want to take a look at ten cognitive biases to look out for as a developer. profile image
Full stack is my JAM! I am a web developer working with everything JavaScript.