Micro Frontends
And how Napoleon Bonaparte might have inspired it.
If you are a big history fan and love daydreaming about the most effective war strategies, chances are you’re also a big fan of the war of the third coalition.
Why am I starting a blog with this? Well, one thing we all picked up from that war is one of the things that made Napoleon Bonaparte the best general in history (In my opinion) — SPEED!
Again I hear you ask, how is this related to micro frontends? Well, let’s talk about how Napoleon achieved that speed.
Napoleon divided the French army into smaller armies. Each had its infantry, cavalry, and artillery, making them as independent as possible. As long as each of the smaller armies understood its main objective and strategy, all that was left for them was to go after that plan “In their way”.
In the end, although multiple ‘independent’ armies achieved the victory, it was seen as a French victory (Or Napoleon's victory).
Now that I’ve set the scene about wars and history let’s get on to the main topic because you will see how it aligns.
What are micro frontends?
It is an architecture that allows you to develop and host different parts of the front end independently and still displays them as a unit (i.e., having different armies working independently but towards the same goal).
How does this work?
So there are 3 concepts you should keep in mind regarding micro frontends.
- Host page: This is the foundation of the micro frontends. The page connects all the micros and provides the framework it will use to display them (Think of this as Napoleon), and as you can tell, it is also a micro frontend. Its function is simply to host all other micro frontends. (Please don’t ask ‘what if one of the micro frontends hosts another micro?’ because that’s a rabbit hole you will have to dive into on your own👀).
- Micro frontend Framework: This is not a framework in the sense of ‘Angular’, ‘Springboot’, ‘Django’, ‘NestJS’, or ‘Vue’. No, this is called framework because it aligns with the native definition of a framework: ‘A support structure or system that holds everything together.’ That’s simply their purpose — to hold all micro frontends together from the host page.
- Micro frontends: These are the main characters of this saga (the stars), the mini armies. Simply put, they are the component-like websites that are put together on the host page by the micro frontend framework (Explaining them further will ruin their excellence).
What’s the advantage of this architecture?
- Team scalability: You can have separate teams working independently but towards the same goal, meaning you can have a team that works on the home page micros, a team that works on the cart micro, a team that works on the sign-in and sign-out micros (depends on how you want to divide your armies of-course), and the only conflict these teams will have is: ‘Why haven’t you finished your part yet?’.
- Strategical: Given that each team can work independently and finish their tasks without depending on one, the application can be built much faster. Another thing is that since the host team knows the end goal of every micro, they can now focus on long-range deliverables, making it easier for them to manage expectations.
- Technology agnosticism: Although, as frontend engineers, we can work with any frontend library/ framework we like, it goes without saying that we have preferences and would like to stick with them if possible. With micro frontends, as long as the host page maintains the standards and contracts of the micros, you can have a team of Angular developers working on one micro front-end, a team of Vue developers working on another, and a team of React developers working on another and in the end, you end up with one app built by three different people.
But like Itachi Uchiha once said, ‘Every Jutsu has a weakness’, you can never win this without losing that, or to put it as we were told growing up, ‘Every genuine gain always requires a sacrifice’, and it is important to know the sacrifices before going after the gain. Let’s now look at your losses when using this architecture.
What’s the disadvantage of this architecture?
- Complexity: Given that all of these micro apps are independent apps on their own, they still have to work as a unit at the end of the day. This is where you realise that the advantage of ‘Team Scalability’ is a double-edged sword, and the lethal side is towards ‘Strategical’ advantage. Maintaining synchronicity can be a real headache. Honestly, how do you even approach such? Do you manage each team in ‘wu wei’ fashion, allowing every team to keep their ‘independent’ germ and hope at the end everything ‘syncs’ given that the end goal and contract between teams have already been communicated? Or do you take away their ‘independent’ germ and start micro-managing every team to follow the plan to the tee to assure yourself and stakeholders that the deadline will be met? The problem of maintaining synchronicity is not only with timing but also with the end products themselves. How do you deal with design inconsistencies? How do you ensure what team A did aligns with what team B did?
- Communication: As I’ve mentioned above, although these systems can work on their own, at the end of the day, the goal is to have them work as a unit. Working as a unit implies communication, and deciding on a neat communication channel between apps can be a headache. If you remember correctly, the main reason Napoleon lost the seventh coalition war was a miscommunication between the troops. Napoleon decided to use the divide-and-conquer strategy against the British and the Prussians. Although it worked, it wasn’t seen to the end because, as we all know, the divide and conquer strategy heavily relies on immediate action to conquer after the division. However, that is not what happened; due to ‘miscommunication’ among the French troops, Napoleon's only achievement was dividing the British and Prussians. Because of the lack of ‘immediate’ conquering, the British and Prussian troops managed to reunite against him at Waterloo, subsequently leading to him living alone on Saint Helena island. He eventually died alone there from stomach cancer. Imagine that you lived your whole life as a warrior, but instead of dying as a warrior, you just end up dying alone. The horror. Sharing this story with you just shows how important it is to have an effective communication channel between your troops (micro apps), and deciding, building, and maintaining this communication channel can potentially lead you to hate this architecture.
Conclusion
The advantages of micro frontends heavily outweigh the disadvantages when applied to large applications (e.g. amazon.com). Although it is beautiful architecture and the current buzz, please don’t forget that it was meant to create a separation of concern. We only need a separation of concern solution when the project is large enough. One does not use a nuke in his apartment in an attempt to kill the spider behind the stove🙂.
