In a nutshell.
I have seen the term ‘Micro Front-end’ a few times now and I didn’t really know what it was. So I went on a journey to find out exactly what it is.
The idea of the micro front-end is based on the thought that a web-application is based on a composition of features. All these features can be owned by separate teams that all have a different idea about the feature since they all have a different mission they care about.
The micro front-end idealogy features some core ideas. They can be seen as guidelines on which you can build a micro front-end.
- Be Tech Agnostic.
All teams should be able to update and choose their stack without having to coordinate with the other teams.
- Isolate Team Code
Don’t share a runtime environment, even if everyone uses the same frameworks. Build apps that are self-contained and don’t rely on a shared state or global variables.
- Set Team Prefixes
Agree on naming conventions where isolation is not possible yet. In CSS, Functions, and Storage to avoid collisions and make it clear whose code it is.
- Try to use native features where possible
If it’s not possible to use native events, try to keep APIs as simple as possible.
- Build a Resilient Site
Most, if not all, of these core ideas, talk about teams, but you can easily apply this to solo projects as well. Though it might sound weird at first.
A webpage consists of multiple components. If you count all smaller components you would have maybe ten buttons, a footer, a header, content, etc. More globally you could define all components that work together as a single micro front-end. You would have ‘navigation’, ‘cart’, and ‘product’ in a simple webshop.
These do require some of the same data and can call the same API for getting that data. But the components themselves don’t need to have the same framework. And some might even be a child of another parent micro front-end component.
For communicating between components you couldn't choose something like React states because the child may not use React. But one thing all these components can read and write is HTML attributes.
In most solo projects, working like this wouldn’t make a lot of sense. It could be a lot of fun, and you would certainly learn a few things while working with multiple frameworks.
You would achieve the same thing when working solo as you would in a team setting. You would create multiple projects for different parts of the project such as navigation or product page. And you would connect them together using more native ways instead of states.
The micro front-end idea is very interesting to me, but I would be reluctant of using it in any real project. The idea is there but it could be polished. And while this article only goes over the very basics it could be interesting to see if this ever becomes more mainstream.
In my opinion, the use of React components is just as good as a micro front-end. But I can see why this could work in enterprise-size applications. If you want to read more you can check out the official site here.
Thank you for reading and have a good day.