When Micro-Frontends Aren’t the Right Choice

Micro frontends are definitely a trending topic. They receive significant attention by promising better separation of concerns, team independence, and ultimately – quicker delivery. But after years of excitement, I found myself recommending against them. Here’s why.

It’s Not a Rant#

Despite the title, this article is not about ranting. In fact, it’s quite the opposite.

When I first read Building Micro-Frontends: Scaling Teams and Projects, Empowering Developers by Luca Mezzalira a few years back, I was thoroughly hyped about the idea, to say the least. I quickly found myself thinking about how I could use it, and more so, how to pitch this concept to stakeholders.

However, when I finally reached a position to advocate for the implementation of micro-frontends and could have utilized them in a production-scale app, I ultimately decided to advise against them.

All The Shiny Things#

Last year brought me lots of reflection. I found myself questioning many approaches that had seemed natural to me, digging deeper into the “philosophy” of software engineering.

While this journey is still ongoing, I’ve already become more pragmatic in my approach. The harsh truth is that every technology-related decision comes with trade-offs.

• We trade simplicity for better performance.
• We trade autonomy and control for the convenience of external dependencies.
• We trade scope for time to delivery.

And these are just examples – the list goes on and on.

In our constant chase for better technologies and abstractions, we tend to forget that every decision has its implications. While it’s easy to see the benefits, identifying the drawbacks isn’t always as straightforward.

The Not So Obvious Parts#

The promises of micro-frontends are certainly tempting. I’m confident that many companies successfully reap their benefits. However, every attractive solution comes with its costs. Here are the key considerations I evaluated:

1. Scale Matters
   When deciding if micro-frontends are right for your organization, consider both the size of your teams and the scope of your projects. Micro-frontends excel in large applications where multiple teams can independently develop and maintain different parts of the frontend. However, for smaller teams, this approach may undermine developer experience and slow down delivery.
2. Complexity Overhead
   Micro-frontends are inherently complex – they impact architecture, deployment processes, and ways of working, while requiring teams to build new competencies. This represents one of those “not easily reversible changes” that becomes difficult to abandon once implemented.
3. Performance Trade-Offs
   Splitting the frontend into multiple micro-applications may lead to increased load times due to dependency management overhead, additional API calls, inefficient bundling strategies, and many more.
4. Tooling and Maintenance
   Setting up the tooling for micro-frontends (e.g., module federation, independent deployment pipelines) is not trivial, and maintaining these systems requires additional effort.
5. Repetitiveness
   Micro-frontends are not designed primarily for reusability – they are designed to enable teams to work in parallel. This makes component duplication is somewhat inherent to the architecture. For smaller teams, this trade off is difficult to justify.
6. Organizational Challenges
   While the vertical approach to micro-frontends (e.g., separate applications for product catalog, basket, checkout) sets clear boundaries, things can become more complex with sophisticated approaches like horizontal splitting (e.g., separate applications for header, navbar; essentially components on the same page), nesting, etc.

While all these challenges could be mitigated, the real question is – should we mitigate them?

One Size Doesn’t Fit All#

In software architecture, every situation is different, and there’s no universal solution. When making architectural decisions, we should always consider our current circumstances, including:

• What problem are we trying to solve?
• What timeframe do we have?
• What team do we have?
• Can we clearly identify domains and split the application accordingly?

In our case, the main challenges were clarifying ownership and balancing modern feature development with maintaining a mature codebase.

The ownership issues were primarily organizational and managerial in nature – making architectural decisions before resolving these wouldn’t have been prudent.

To balance legacy and modern stacks, we took an alternative approach, which we call multi-frontend. Instead of fully embracing micro-frontends, we delegated routing at the infrastructure level, allowing us to serve separate frontends for different sections of the application. This approach gave us the flexibility to build modern features independently while keeping legacy systems intact.

Given our small team size, this approach avoided the complexity of managing fully independent micro-frontends while keeping things modular, concerns separated, and enabling parallel work on different parts of the application. This setup also positions us well for a potential transition to micro-frontends when appropriate.

Though this has its trade-offs (such as duplicate dependencies and full app reloads), it enables us to both build modern features and maintain existing ones effectively within the constraints of a small team.

Our current continuous deployment process already supports multiple deployments per day, with quick turnaround times despite needing to deploy all services simultaneously.

For now, this approach strikes an effective balance between progress and pragmatism. We remain ready to reassess and adapt as our needs evolve.

When to Use Micro-frontends#

Just to clarify, all the above doesn’t mean that micro-frontends are bad by any means. They for sure excel in many situations, but for our use case, these advantages didn’t outweigh the downsides. It’s worth clearly stating that:

Micro-frontends were primarily designed to facilitate rapid team scaling by allowing teams to work in parallel.

That’s why they’re best suited to large organizations with distributed teams and possibly diverse technology stacks.

This makes them a less ideal choice for relatively small companies where the added independence wouldn’t justify the costs.

In our situation, we can already benefit from rethinking our approach to ownership and modularity without adding excessive complexity that ultimately wouldn’t bring us much value.

Summary#

Does this mean I don’t love micro-frontends anymore? No! I’d still love to use them, but only when they’re clearly the best choice for a given problem.

My key learnings#

1. Context Is Key
   No technology is universally good or bad. Everything depends on the organization’s current needs, future vision, team structure, and goals.
2. Beware the Hype
   Trends in technology can be tempting, but we should carefully identify, understand, and evaluate all the trade-offs.
3. Stick to Simple as Long as Possible
   Simplicity is a value on its own. It’s far easier to add complexity than to reduce it. Before adopting a new architectural style, we should carefully consider whether simpler solutions can achieve the same results with fewer trade-offs.
4. Start Incrementally
   If you can split a process into multiple steps, you should do so. The feedback gathered between iterations is invaluable.