DEV Community

Cover image for 5 Reasons for Doing Microfrontends
Florian Rappl
Florian Rappl

Posted on

5 Reasons for Doing Microfrontends

By now most people have heard about this microfrontends thing. After microservices this seems to be the next target for decoupling large systems. As with microservices this will not be for everyone.

Personally, I think before starting with microfrontends you should be aware of why you want to do them in the first place.

Obviously, multiple solutions to microfrontends exist. While I'm personally advocating React as a basis for microfrontends the whole approach works with any technology and any implementation pattern.

If you are interested in starting with microfrontends then check out Piral. Don't forget to ⭐ it!

1. Independent Teams

Independent Thinking

If you develop in multiple teams then the organizational overhead becomes striking. Communication needs to happen at least on a daily basis. 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 for microfrontends require at least a shared build system or a common layer to be touched (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 has an impact also 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 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. The initial feature may be developed and brought online within minutes to days instead of weeks to months.

The faster time to market is also possible by sharing already some of the used resources and functionality. Instead of developing a new application from the ground up (incl. things such as authentication, logging, ...) all these things should be given 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.

Consequently, we'll add things in our code like:

if (hasFeature('foo')) {
  // ...

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 a long, changing some parts to also evaluate if 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

One Boss

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 now 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 definitely 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 frontend 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 now 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 (yes, even some guys developing Angular!), 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 really 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.


Microfrontends are not a silver bullet. They can help and provide value when the circumstances are right. If none of the reasons above play have any importance for you then chances are high that you don't need a microfrontend solution.

When you go for a microfrontend solution be sure to check out Piral.

Top comments (7)

dbredvick profile image

I love the idea of micro frontends. The perks you mention are exactly why we were going to break up our FE at my last company.

Where do you decide to breakup monolith frontends though?

Let’s use an e-commerce site for an example, say Amazon.

I would break out:

  • user profile
  • checkout
  • content pages
  • navigation experience (CDP, PDP)
  • home page (maybe)

I have a hard time determining what is “too many” different front ends.

florianrappl profile image
Florian Rappl

We usually break by feature, so the decomposition you've described seems valid.

Just note:

  • Content pages would potentially be just "content page", where the actual content comes from a headless CMS or other content delivery service
  • The navigation would not be a dedicated microfrontend but rather be distributed among all microfrontends (each one could decide what to deliver to the navigation); the mentioned product detail page would either be part of the "product experience" microfrontend or in its own (depending on the business context and team structure)
  • The home page would potentially be centralized, however, its content distributed like the navigation; e.g., the recommendation microfrontend team could provide a sneak peak of their best recommendations for you on the home page

While some features would certainly be contained in dedicated or even "stand alone" pages, many features would just be scattered and recomposed.

But that's just our take - any decomposition is valid if done with the right reasoning.

jeastham1993 profile image
James Eastham

Hey Florian, fantastic article. I think it's only natural that micro services extends to the front end as well.

I'm interested, do you have any links to any tutorial type article's that explain creating a 'micro front end' app.

I understand the concepts, but can't get my head around making it cohesive.

florianrappl profile image
Florian Rappl

Thanks James always happy to hear positive feedback.

Sure I've some links for you:

Also make sure to check out our tutorial which goes step by step. You can stop at any time when you feel you know enough for the moment:

We would appreciate if you could give us feedback. Is the tutorial understandable? What is missing? Did something not work? Anything we forgot to mention? Thanks!

jeastham1993 profile image
James Eastham

I really like the look of Piral, thanks Florian! When it comes to developing the front end side of the app I'm working on at the moment I will dive a little deeper :)

Thanks for taking the time to respond.

alonronin profile image
Alon Valadji

Do your micro frontend the right way with Fronty:

florianrappl profile image
Florian Rappl

Cool project, where's the documentation?