This article gives you a brief knowledge on implementing Micro Frontend Architecture using Module Federation

By Rishabh Gupta — “A Whimsical Tech Guy”

---

Micro Frontends are to Frontend what Microservices are to backend. Coined in 2016 in Thoughworks Technology Radar , they bring the benefits of independent deployability and autonomous teams to Frontend. In short, Micro Frontends are BFF — Backend for Frontend (metaphorically and literally)

Need for Micro Frontends (MFE)

When the client-side of a web application is built as a single codebase, we run into a problem of very big front-end codebases commonly referred to as a Front-end monolith. This makes development difficult for different frontend teams which may be working on entirely different parts of the web app. Some of the most common issues with a Monolithic Front-end are:

1. As the web app evolves and becomes more feature-rich, the Frontend monolith becomes overloaded and subsequently inefficient which may lead to system slowdowns and in the worst case, performance degradation of the live app.
2. Scaling a very large and heavy frontend codebase can very soon become a development bottleneck. Monolithic codebases take up much more time to push updates as compared to a backend service.
3. Management of a monolithic codebase becomes increasingly difficult as the team size increases. The In-feasibility of independent deployments means if one part fails, the entire system gets stuck.

What are Micro Frontends

Micro Frontend Architecture can be described as an architectural style where independently deliverable frontend applications are composed into a greater whole. A single Micro Frontend serves as a modular piece of an application that can coexist with other Micro Frontends.

Benefits provided by a Micro Frontend Architectural style:

1. Decoupling development for different parts of the same web app
2. Helps avoid complexities that come up with a monolithic codebase.
3. Separate teams can work on different parts of the app with their own development setups and timelines
4. Separate Deployment pipelines for different Micro Frontends
5. Each team can use its own framework for that part of the app if they so desire.

Tools/Frameworks that can be used to set up a MFE Architecture

There are multiple ways to achieve a Micro Frontend kind of Architecture for the codebase. The kind of framework/tool that can be used depends on the type of Integration that we want for our Micro Frontends. There are two kinds of Integration that we can have with MFEs:

1. Run-Time Integration — Different tools available that work this way are:
2. Piral
3. Luigi
4. Single-Spa
5. Module Federation
6. Build-Time Integration — Tools available that work well this way are:
7. Bit Components

Since we are using Module Federation, we must have a good understanding of the tool that we are going to use. Here is a detailed article on all things Module Federation

Implementation of MFE Architecture at CaratLane

At CaratLane, we have a big Frontend Codebase with more than 1000 React Components and Containers. The codebase is a monolith in itself and has been getting bigger as more features are being built into the client-facing app. This sometimes leads to development bottlenecks where an issue in one part of the app impacts development in some other completely independent part of the app. To minimize the frequency of such issues as the app gets bigger and bigger, we have pre-emptively decided to move to a Micro Frontend Architectural style from the current Monolithic Architecture.

For our use case at CaratLane, we needed Run Time Integration and for that, we are using Module Federation. It is a tool by Webpack and is available only with Webpack 5.

Module Federation Plugin has to be included in both, the container repo as well as the remote repo. On the remote side, we expose the components that we want to be consumed by the container. On the container side, we use remotes to access the shared components.

On the container side, the plugin configurations look like follows:

Here, the most important property is “remotes”. This is used to tell Module Federation what all apps will be hooking into the container. For instance, here repo2 is the name through which we can access components from the Micro Frontend hosted at the mentioned URL.

On the Remote side, the plugin configuration looks like following:

On the Remote side, we use the “exposes” property to list out all the different components that we want to expose from the Micro Frontend. For instance, here we are exposing a component named repo2 Index from the Micro Frontend.

This component will be available to the container repo through the remoteEntry.js file. We set this name using the “filename” property.

Ideally, to keep the size of remoteEntry file to a minimum, it is best to use the same version of packages across different Micro Frontends. But that is not always possible and as we come up with new Micro Frontends, we will have packages that differ in their versions.

For instance, in our case, our container repo is on React 16.x and it is difficult to upgrade the React version to the latest one without spending a lot of time refactoring the code. But we also wanted to use the latest version of React with the new Micro Frontend in order to be able to use the new features. To work with different versions of react across different repos, some extra configurations need to be added to the Module Federation Plugin.

On the container side, the configuration now looks like following:

While, on the remote side, the configurations now look like following:

This is the basic structure that is needed to integrate the Micro Frontends and make the setup work. But, there are lots of other things that need to be taken into consideration when setting up a MFE Architecture for Production level apps.

Some other things that we added to our Micro Frontend setup include the following:

1. Routing — Routed should work independently in the Micro Frontend as well as from the container.
2. State Sharing — There are some state values that need to be accessed in different parts of the app and even across Micro Frontends. For this, an efficient state management setup is added.
3. SEO — We extensively use Server-Side Rendering to help with SEO. Care was taken to avoid any issues with SEO when moving from a monolithic architecture to a Micro Frontend based architecture

We will have separate blogs with details on how we implemented the above features in our Architecture. Stay Tuned!!!

---

References:

[embed]https://github.com/module-federation/module-federation-examples[/embed][embed]https://github.com/module-federation/module-federation-examples[/embed]

---

Meet The Team!!

Author

Rishabh Gupta

Editor

Seema Jain

---

We at CaratLane are solving some of the most intriguing challenges to make our mark in the relatively uncharted omnichannel jewellery industry. If you are interested in tackling such obstacles, feel free to drop your updated resume/CV to careers@caratlane.com!