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
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
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.
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.
Top comments (7)
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:
I have a hard time determining what is “too many” different front ends.
We usually break by feature, so the decomposition you've described seems valid.
Just note:
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.
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.
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:
docs.piral.io/tutorials
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!
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.
Do your micro frontend the right way with Fronty: github.com/frontyjs/fronty
Cool project, where's the documentation?