What are Micro frontends?

The tech world is obsessed with organizing things. Micro frontends are just another way of organizing your code to be precise. What do I mean by that? Well, let us find out.

Most of us use a monolithic architecture while developing applications. This means it usually has all the code in a single project. Both the backend and frontend rely on the same project. Probably within different folders — frontend and backend.

Benefit — A developer has both sides of the project and can easily work on it without worrying about breaking changes on either end of the project when they come in.
Drawback — It becomes really heavy when you are starting up the project. Merge conflicts. Dependencies not in sync and so on. Installing things that are not at all concerned with their part of the work.

Then some projects separate the front and back ends into different projects so that teams can work on them independently. They can use a range of technologies to get things done.

Benefit — Ease of doing things. Project Managers can separately track both projects etc.
Drawback — Two projects to maintain. Two deployment environments etc.

Upon Further Breakdown

Then come micro frontends. This is breaking down your front-end application into further modules and hosting them separately. If you are a backend developer you might have come across micro-services. The idea is similar.

Micro frontends allow you to break down the project into distinct modules that can be worked on by different engineering teams. This allows more isolation and better use of technologies. Say you are building an e-commerce app. The Products and the Cart components can be broken down into separate micro frontends and worked upon by different engineering teams without affecting each other.

Although it feels like a small task, it involves a lot of things to think about.

1. One of them is how will you host the separate frontends. This is usually done using some orchestration tools. The different micro frontends are usually connected using a container app.
2. What about styling? Won’t the two teams follow different themes? This is taken care of using a UI library that is shared amongst the frontends.
3. What about maintaining states? This is done using independent API calls.
4. What about authentication and authorization? Well, this is taken care of using a central Auth server.

Now the complexities are much more than this. But for the effort, we get more organization, better scalability, and last but not least, better peace.

If you are building small projects then it would be an overkill. But you can experiment with it and get a taste of the architecture. For bigger projects, it is a recommended approach.

Check out this amazing course by Stephen that beautifully captures this essence.