Micro Frontend Architecture at CaratLane
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)
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:
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:
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:
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
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:
We will have separate blogs with details on how we implemented the above features in our Architecture. Stay Tuned!!!
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 email@example.com!