I lately have seen a lot of articles emerging around Microfrontends and how to implement them. Sadly, most of them don't answer a simple question: Who does even need Microfrontends?

Before I want to answer this question, let's do a small recap on what a Microfrontend is and what not. A Microfrontend is tightly coupled to Microservice (who would have guessed that 😜). Here, I do not mean the natural coupling of a Frontend to a Backend, but more of the design pattern of a Microservice. By definition, Microservices have three core values:

• They are loosely coupled.
• They can be deployed anywhere and standalone.
• They can scale well.

These core values led to the Microservices popularity as they helped to migrate or avoid a monolithic architecture style where everything depended on each other which is hard to scale and maintain.
The same goes for frontends: If you end up (like me) building a huge frontend application with many features, you find yourself in a maintenance and responsibility hell (regardless of how well you test). Microfronends help to avoid this, by sticking to the core values of microservices (loose coupling, easily deployable, good scalability). Therefore they usually have one shell application and multiple remotes. The shell applications host those remotes (maybe one at a time, or multiple at a time). They are mostly loaded on runtime. You then share certain dependencies (like a common framework) and can load it from different servers. That mostly s serves the three core values of Microservices:

✅ loosely coupled: The shell and remote need to work on their own. You can share libs via e.g. Module federation.
✅ deployable anywhere: As it's just static files, any Webserver can easily serve the files.
✅ scales well: Webserver can be easily scale horizontal. Additional the teams working on them can scale too, as any team can focus on the domain of the microfrontend.

The main difference to Microservices lies in the weight of these 3 factors: For a frontend it is much easier to scale and deploy easily, while it is much harder to be loosely coupled. A simple example: Imagine two product teams, one working on the product listing of an e-commerce website, while the other are working on the search bar at the top. Now imagine, the UX designers decide to update the design principles and the search team adopts them faster than the product listing team. The whole website could look out of place (recently happened on the twitter renaming to X).

This gives already a hint on who really needs Microfrontends: As long as you are a one-man show or a small team, you should definitely avoid using a Microfrontend architecture at all. It just brings complexity overhead, which you should avoid in smaller teams. Even if you consider your teams might scale at a certain time, you should invest more in a domain-driven decoupling (maybe in different libs in a monorepo) than a Microfrontend architecture.

So, who needs in the end Microfrontends? In my experience there are only two types of projects that needs such an architecture:

1. Huge development teams (+3 teams on the front end) that need clear structures and consistency.
2. Applications that should be extendable by external plugins. For example, a dashboard that can be extended by external widgets.

If your application/website does not fall into one of the above sections, simply do not consider a Microfrontend architecture. Try to split your frontends into domain-specific sections and serve them in a classical way. Use style guides and shared libs to ensure consistency.

About me: I have been building a Microfrontend architecture since 2019 for Cumulocity (read more about it here). Contact me if you want to discuss Microfrontend architectures or any related work.