Discovering Micro-frontends

Micro-frontends: set the max-width of your website to 10px and you’re good right? WRONG.

Micro-frontends don’t actually have anything to do with the visual size of your frontend (neither are they related to the size in memory of your frontend’s codebase).

In this post I’ll be talking about the main concepts I learned while reading up on micro-frontends for the first time. My main sources were:

What are micro-frontends?

Another way to refer to micro-frontends is as “small independent frontends that can be composed into a larger frontend”, imagine putting a frontend in a frontend.

To get more technical, micro-frontends can be said to be:

“An architecture style where the codebase for a monolithic frontend application is replaced by smaller independent codebases. Each of these corresponding to an independently deliverable frontend application, or micro-frontend, which are then used to compose the final resulting frontend.”

There are various ways of deciding how to split a monolith into micro-frontends, for example you could make certain sections of a page their own micro-frontend or split the monolith by page.

Why micro-frontends?

Understanding why micro-frontends came to be doesn’t require too much effort if you consider why microservices came to be. Splitting a monolithic frontend into micro-frontends is similar to splitting a monolithic backend into microservices. Unsurprisingly, many of the benefits of microservices are shared by micro-frontends:

A key benefit I want to underline is the organizational aspect of micro-frontends: teams can make local decisions regarding their own part of the frontend as opposed to global decisions which in the case of a monolith would need to be discussed and coordinated with many more people.

A quick example

Imagine, a website where you can search and apply to jobs. This website has two micro-frontends, a “Browse Jobs” and an “Apply to Job” micro-frontend. Each micro-frontend has their own cross-functional and independent teams, respectively team A (red) and B (blue):

Liquibase overview

The key takeaways here are that:

Why not micro-frontends?

After reading a bit about what micro-frontends are and what benefits they can bring, I started looking at how to actually implement micro-frontends. It turns out that there are multiple architectures that support micro-frontends.


In my personal opinion as a total micro-frontend newbie: my first impression regarding the implementation of micro-frontends is that doing so is complex. Especially compared to a component model.

In You probably don’t need a micro-frontend, Colin Eberhardt discusses why micro-frontends are probably not the best choice most of the time. You can read more about the reasons he says this but one reason I can’t argue too much with is the complexity that is brought into a project as a con to the benefits of micro-frontends.

Not for small projects/teams

In considering that one of the key benefits of micro-frontends are the organizational aspect, if the project is being built by a team of only a handful of developers with no immediate plans to scale the project, then micro-frontends might just introduce needless complexity.

In this cases it might be wise to start with a monolith for simplicity and if the need occurs there is always the option to start incrementally moving towards micro-frontends.


In I don’t understand micro-frontends, Luca Mezzarila addresses a discussion started by Dan Abramov questioning the concept of micro-frontends as opposed to a component model. I liked Luca’s main idea that one is not trying to replace the other, that the right tool should be chosen for the right job, and that that decision depends on the full context of the problems at hand.

That’s all I’ve got on micro-frontends for now, I’m curious as to how this architectural style will evolve in the future and what its use cases will be.