5 Reasons for Doing Microfrontends
Tags: microfrontends, react, distributedsystems, architecture
Published: 2020-01-25 13:44:47

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](https://dev.to/florianrappl/microfrontends-based-on-react-4oo9) the whole approach works with any technology [and any implementation pattern](https://dev.to/florianrappl/microfrontends-from-zero-to-hero-3be7).

If you are interested in starting with microfrontends then [check out Piral](https://github.com/smapiot/piral). Don't forget to :star: it!

## 1. Independent Teams

![Independent Thinking](https://media.giphy.com/media/3o6UBiAQ9Ws8UWdmqA/giphy.gif)

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

![Faster](https://media.giphy.com/media/3o6Mb9cGKe3JzhbqPC/giphy.gif)

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

![Personalization](https://media.giphy.com/media/LbCRnegwCe208/giphy.gif)

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:

```ts
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](https://media.giphy.com/media/xT5LMKC6Z1TVa0otQQ/giphy.gif)

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

![Freedom](https://media.giphy.com/media/gKqTU4blja8PHKzCg2/giphy.gif)

In the last two years the frontend technology has pretty much stabilized. Sure, with [Svelte](https://svelte.dev) around the block technologies such as [React](https://reactjs.org) 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](https://angular.io)!), 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.

## Conclusion

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](https://piral.io).