How to Compose Micro Frontends at Build Time

We have been building npm packages and using those inside the frontend application for eternity now. Build time composition of Micro Frontends is nothing but creating micro frontend modules which can run independently but are published as npm packages instead of deployed as a javascript bundle. These modules can then be installed as an npm dependency inside a container application and rendered wherever required.

The orchestrating pattern is called as build time composition of micro frontends because the container with the installed micro frontends becomes the single deployable application. Releasing a change from a micro frontend would involve the following steps:

1. Publish a new version of the micro frontend as an npm package to the npm repository. Each micro frontend should have its own independently running continuous integration pipeline which should publish the new version of the micro frontend in the end.
2. Update the micro frontend package version in the container app.
3. Generate and deploy the container app bundle now containing the latest changes from the micro frontend as well.

Now, let us walk through a simple e-commerce application developed using this pattern.

• The Catalog micro frontend shows the list of products available and gives the capability to add a product to the cart
• The Cart micro frontend then displays the products added to the cart. For the sake of simplicity, the added products are stored in the browser's storage and read in the cart micro frontend.
• The Container is the actual application responsible for installing the Catalog and Cart micro frontends as npm packages and rendering those at appropriate places. The dependencies section of the package.json file of the container looks something like this:

Once installed in the container, the micro frontends can be consumed as:

import Catalog from '@mfe-patterns/catalog';
import Cart from '@mfe-patterns/cart';

By looking at the directory structure, we can notice that each micro frontend has its configuration and can be developed and published independently.

The whole code of the above app can be found on this Github repo.

Since we have understood the integration pattern now, let's discuss some pros and cons of it:

Pros

• A very simple and very well-known technique in component-based architecture.
• Easy to get started with. Don’t need to worry about the setup cost included in the Run Time composition of micro frontends.
• Micro frontends can be lazily loaded in the container app enhancing the performance of the application.

• This is the only available option to build micro frontend architecture in cross-platform solutions like React Native.
• A design library exposed as an npm package can lead to design consistency in the micro frontend architecture.

Cons

• Even though the micro frontends can run independently, once changed and published, the version has to get updated and deployed in the container. This can lead to a lot of communication overhead.
• The container should only be responsible for rendering the micro frontends. If the data end up flowing from one micro frontend to another via container application i.e. if a lot of coupling is introduced, then the application will just be another Distributed Monolith.

I would end this article by mentioning that this composition pattern is very convenient in the case of mobile micro frontends or when we need to build reusable modules. Since the pattern can lead to coupling issues between micro frontends and container, this should only be used when Run time integration of micro frontends is not possible.

To understand which micro frontend communication technique can suit this pattern, check out the article on 5 different techniques for cross micro frontend communication.