Should You Switch to Micro Frontends? Here’s What We’ve Learned

As web applications grow in complexity, many development teams are hitting the limits of the traditional monolithic front-end architecture. If your app is getting harder to maintain, onboard new developers, or scale independently, you might have heard of Micro Frontends as a potential solution. But is it the right fit for your team?

What are micro frontends?

Micro frontends are a way to build complex applications with many components. Instead of having one monolithic application, you would break it down into smaller components that can be developed independently.

5 Reasons for Switching to Micro Frontends

1. Independent Teams

If you develop in multiple teams, then the organizational overhead becomes significant. Daily communication becomes necessary, often creating friction. The alignment required to control development and deployment is becoming infeasible.

With microfrontends, the scalability in terms of development resources becomes much easier to manage. Generally, each feature can be developed by an independent team. Each team can autonomously publish its features without any required alignment.

Some approaches require a shared build system or common infrastructure layer...(e.g., a reverse proxy). While such things could still be tackled upfront, they make the whole solution more complex to be set up correctly initially. My recommendation is, therefore to look for solutions that already work after initial set up.

2. Faster Time to Market

The independent nature of microfrontends also has an impact on the time to market for individual features. While a monolith will become slower and slower in its feature development, a microfrontend will keep the pace.

Naturally, refactoring and improvement of the underlying technology will need to happen here, too; however, the pace that is possible by a cycle consisting of

• Start a new project
• Develop the MVP
• Ship the MVP
• iterate over the MVP (develop and ship)
• Go into maintenance mode

For each new feature is mighty. Initial features can go live within days—sometimes even minutes - instead of the usual weeks or months. The faster time to market is also possible by sharing some of the resources and functionality. Instead of developing a new application from the ground up (incl. things such as authentication and logging), all these things should be provided by a common layer. My recommendation is to go for an app shell approach to cover things that should be common already in a shared component.

3. Feature Flags

It's wonderful to have individual microfrontends composed (or stitched) together as one app. But quite often, product owners want to go one step beyond the technical composition: They want to use the modularization also for business purposes.

Ever had the case that a certain frontend functionality should only be available to certain users? I guessed so. Sure, admin functionality should only be available to admins. While the frontend should not be used as a protection layer (this is still verified in the backend) we also don't want to show things that cannot (or should not) be used.

This is quite a bad style. Our code is now full of things that will most likely change. What if foo is just true for everyone? What if the feature is deactivated for everyone? What if tomorrow a new condition comes along, changing some parts to also evaluate if the bar is active?

Since we already have proper modularization its quite simple to add feature flagging. All we need to do is to introduce conditional provisioning of a module via feature flags. That's it. No code change at the functional level of the module, just introduce feature flagging and its management on the provisioning layer.

While things like this may also work in classic monoliths, they require more implementation effort. With microfrontends the architecture is already fully prepared for it. My recommendation is to choose a microfrontend framework that allows conditional provisioning per user.

4. Single Responsibility

Even though microservices are not the solution for everything, they are advocated as such. Yes, they are certainly a good solution in many (or even most) cases, but very often a monolith or other form of service-oriented architecture may be at least as good.

Nevertheless, having a dedicated service (with a team responsible for it) in the backend is a good start. Replacing the monolith with different microfrontends is a great continuation as the additional dimension of cutting teams can be used in many ways.

One possibility is to start with full-stack teams. As such the team doing the backend module (microservice) is also responsible for the frontend module (microfrontend). Great!

While the service and its frontend are two different things from a technical point of view, they are related or even the same from a business point of view. Having a single business capability or feature from a single responsible team is certainly an advantage.

One of the problems is that a typical user journey is quite often touching multiple business capabilities. My recommendation is therefore to use a framework that also allows dynamically using components from some microfrontend in another microfrontend. The relation must be weak to still allow individual feature flagging.

5. Freedom of Technology

In the last two years, the front-end technology has pretty much stabilized. Sure, with Svelte around the block, technologies such as React might be challenged again, but honestly, I must yet to be convinced of any advantage. Right no,w the development in a single codebase is just too appealing.

Independent of my personal feelings regarding the future of any framework it's a truth that multiple approaches are out there and that no silver bullet exists. As such we will not only find people with a different background but also existing applications using different (maybe even outdated) technologies.

In a microfrontend solution, all these different apps can work together. A page written with Angular can use a component from a React microfrontend and vice versa. The modal dialog for saving user data may be written in Vue, while the page underneath was done in Svelte.

The problem of a consistent user experience becomes a difficult one. There are many questions arising. Among the most important ones are:

• Are we only sharing plain CSS here?
• How about behavior?
• Are web components a solution for that?

As a result, the freedom of technology should always be considered the least reason for doing microfrontends. My recommendation is to have a clean approach in the beginning but to choose a framework that at least supports multiple frameworks incl. a strategy for their communication.

Final Thoughts

Micro Frontends aren’t a magic bullet, but they can transform how you build, deploy, and scale your front-end architecture - especially in large, distributed teams.        

Further Reading & References

• ThoughtWorks on Micro Frontends: A modern look at how Micro Frontends help scale frontend development and align cross-functional teams.
• Martin Fowler – Micro Frontends: A foundational article explaining the core concept, benefits, and trade-offs of Micro Frontends.
• Webpack Module Federation: Official Webpack documentation on Module Federation—an essential technique for implementing micro frontends.
• Single-SPA Framework: A powerful framework that enables the combination of multiple microfrontends built with different libraries or frameworks.
• Spotify’s Microfrontend Architecture: An insightful case study on how Spotify uses Micro Frontends to deliver a scalable and maintainable user experience.