Deep dive into Micro-frontend

What is Micro-frontend?

In few simple word, it is a frontend development architecture where a Host application has multiple components running separately. The concepts behind this architecture is breaking down a big application into small reusable components so that developers can work separately and change anything in one component without affecting others.

Why we implemented Micro-frontend in our project?

We had a big project. 5 different applications were running individually. All of them were having a different URL and different functionality which was very hard to remember for business people where to go for a simple change.

So, we came up with an idea which was nothing but bring all application under one host application. We introduced micro-frontend architecture and without modifying any code we bring all applications under one host application.

How we implemented Micro-frontend architecture in our application?

We explored 2 ways to implement this.

1. Using <iframe>

2. Using Webpack Module-Federation plugin

An inline frame (iframe) is a HTML element that loads another HTML page within the document. But there are some restrictions when using <iframe>.

a) It loads the entire container. There is no way to share a particular component from a container.

b) If we need to share any data between host and container, the only way to share is through query params. But it can create security issues. If there is some user token needs to be shared across components, it will get exposed to others.

c) Different local storage / session storage will be created for child components.

So we implemented the second method.

Module-Federation plugin is introduced in Webpack version 5. It is a game changer in micro-frontend world. Benefits of using module-federation plugin.

a) We can expose multiple component.

b) All the exposed component we can use in the host. It will act as a child component where we can pass the props from host to them. If some secured data is there, it will not get exposed.

c) Same session storage and local storage will be used across all container.

d) We can change pages using container routes in the host application.

e) Dependencies are shared across all the components.

It looks an easy job to implement. But no, there are still few challenges.

Coming to the challenge part -

a) If any dependency is shared, it has to be the same version across all the applications in package.json.

b) If there is any mismatch of the shared dependency in any of the containers, the whole application can break.

c) For the initial load of any of the container, it can take some time. All the containers should be optimized, load the application in small chunk files, otherwise there can be some performance issue.

d) Chunk file names should be unique for all the containers. Also, we cannot expose a same filename from different container. File name which is getting exposed, has to be different.

For more details, please visit my Medium.

To see real time implementation, please visit my GitHub Repo.