Micro Frontends don’t exist.
Update (17th Oct): a series and a book about Federated Architecture Strategy are on their way. This story may be contain outdated information and some naive affirmations. Please read with caution.
Give back to Caesar…
You must have been reading many things around “micro frontends” recently. But how much do you know about it? What a micro frontend would really look like according to its own definition? What is the right term that defines what is often known as micro frontend? Actually, the story behind the name and its subsequent usage is pretty awkward.
The word micro frontend eventually appeared in 2016. It was described as “Microservices for frontend”. There was a very broad idea behind how micro frontends would be designed… But the term itself quickly went mainstream.
Today, we have figured out how to decouple frontends the right way using Webpack Module Federation but does that make united frontends micro frontends? Not really.
Micro Services for frontend?
What’s a microservice? It is a part of a software architecture strategy where services from a monolith architecture are split into smaller pieces and developed independently. Each service lives on its own. It is reachable through an API gateway and performs a very reduced amount of operations. They’re usually split by domain and used to perform CRUD operations (!).
The misconception and stigma that has later affected frontends start here.
Micro frontends were called like that by mistake. Sorta like the IQ: it actually does not rate the intelligence but the ability to reason.
Technically, a micro frontend must:
- perform a single frontend operation.
- not know about other frontends.
- be part of a greater whole.
Based on those 3 affirmations, any frontend developer can easily spot misconceptions using the term micro frontend. A frontend is not a service, hence a micro frontend is not a “microservice”. The design is intrinsically different and should not be compared. Microservices are usually performing CRUD operations. The way micro frontends are suggested today have nothing “micro” about it. Hence, the only thing micro frontends and “microservices” have in common is that both are developed independently.
Micro frontends may exist but it’s not an architecture and it does not exist the way it was sold to you: it’s a standalone component.
Let’s have a second look at those 3 technical rules a micro frontend should follow.
- perform a single frontend operation.
That is called a component. If you’re using Angular, a micro frontend could be a SCAM component.
2. not know about other frontends.
We can argue about this. How do you reach a micro frontend if it’s in complete isolation? The host application. Technically, you can have separated frontends working in isolation but it doesn’t make sense. The host application is a critical part of the system and it has to know about all the frontends that are hosted.
3. be part of a greater whole.
By using the word micro frontend, we have put some stigma on a solution that is technically not feasible, nor corresponding to the “microservice for frontend” definition. Such a term could only be valid if the frontend was in complete isolation (no host). Comparatively, microservices can run in total isolation and would still perform what they have been created for.
In terms of architecture, there is no micro frontend architecture but Federated Architecture Strategy (FAS) where one or more Federators, hosts, know Federated applications it has to load to ensure the validity of the system.
There is a lot more examples where micro frontends just pwn themselves but those 3 are just obvious. The more you will be practicing Federated Architecture, or Federated Frontends in our case, the more you will understand the misconception behind the term micro frontends as described today.
The Federated Architecture Strategy (FAS)
We cannot speak about micro frontends today without mentioning Webpack Module Federation created by Zack Jackson and inspired by the Apollo Federation. Why? Because micro frontends are in fact — by facts — not micro frontends but Federated Frontends (FF). It’s not giving to Caesar what belongs to Caesar to speak about something that does not exist and was named after a different technology.
As long as frontends will be serving frontends, there will only be frontends. Not “micro frontends”. What we mean by having frontends developed separately and hold by a host application is not “micro frontend architecture” but Federated Architecture.
What we are calling “micro frontends” are frontends following Federated Architecture Strategy.
What’s deterministic to opt in?
I personally have been working with federated frontends for a while now. I’ve been doing researches, tryouts and many presentations about what is commonly called a “microfrontend architecture”. That actually made me realize they don’t exist. And the stigma that this type of architecture style aims only at big projects and big teams is highly debatable. There is not a unique solution when it comes to architecture, hence Federated Architecture can fit any project based on its features regardless of its size or the size of a team.
Let’s assume we’re creating an application. We already know various parts of this application will not change in the next year. Why would we have to recompile those parts again every time we want to deploy changes on some other application? In this case, using FA can leverage webpack module federation. If you’re working in a monorepo environment, you can also take advantage of the incremental builds that would build only applications that have changed. This will make your CD/CI pipeline blazing fast.
Try yourself!
A pretty cool thing to experiment, using app federation, is mitigating desktop and mobile applications. What makes a good mobile application? Probably its ability to serve the least functionalities from your application that is still relevant to the end user. When using FA, you can choose at runtime which frontend to load and which not to load. Isn’t it great? You don’t need a bundle per device or run on DDD to make sure your user gets what he wants. You don’t need to clutter your code with conditional statements to display some component or not. You just configure the host application (federator) to serve the modules of your application (federated). Since scaling is critical when it comes to mobile devices, Federated Architecture may help a lot.
The usage of Federated Application is changing the way we develop applications. It moves any type of dependencies to loose dependencies. Applications are resolved at runtime and can be easily replaced or substituted. Once again, we speak about applications and not micro frontends because some applications may have nothing micro…
Conclusion
This post is not meant to tackle existing hype around micro frontends but I thought it was interesting to put things back where they belong.
If you’re interested in Federated Architecture, I will be more than happy to share with you the good, the bad and the — sometimes — ugly when opting for this architecture. You can reach me out through twitter or just by dropping a comment below, I’ll get back to you as soon as possible.
Thanks for your attention. I really hope you enjoyed the read, it’s all love.
Credits:
