How can modern micro frontends be composed to enhance independent deployments, team autonomy and application scalability? 

One of the main advantages of building micro frontends is independent deployments and releases. With build time composition, we can publish the micro frontend independently but can’t release the app without being dependent on the other micro frontends. This leads to a modular monolith. 

To overcome this problem, it’s advisable to compose micro frontends at run time so that:

• Any change in one micro frontend can be taken to production without worrying about other micro frontends aka independent deployments.
• Each team is free to consider the tech choices within their micro frontend aka Autonomous teams.
• There’s less coupling between micro frontends and more cohesion within the micro frontend aka modular codebase.

Libraries like Webpack Module Federation, Single SPAs, and h-include help teams with run time micro frontends composition, but also mean one more library to understand and manage instead of building the features.

This article will discuss different patterns to compose micro frontends at run time without using any library or framework-specific technique.

1. Reverse proxy composition — each application is an independent SPA

This technique is suitable when the whole page is a single micro frontend. Taking the example of an e-commerce application, Catalog, Cart and User micro frontends can be deployed as three independently running applications on their web servers. But to make it work like a single seamless application, a proxy server is sitting in front of the end user to route it to the appropriate micro frontend according to the URL.

Reverse Proxy Composition

Pros / Use Cases

• Convenient technique for a project re-platforming to new technology. Each team can choose a different UI framework although not always recommended
• Go-to choice for server-side rendering as each frontend can be an independent SSR application.
• Easy to manage as it only needs an anchor tag to route to another frontend.
• There is no need for a container application, unlike build time composition.

Cons

• Only suitable when the whole page is a single micro frontend.
• There will be full page reloads to navigate from one micro frontend to another which can cause delays in the largest contentful paint. Routes within the same micro frontend can continue to work as a single-page app.
• Page layout might not remain consistent as each frontend needs to handle the layout individually or by sharing a library. An additional layer is needed for the reverse proxy server in the overall application architecture.

Please check this github repo for the complete example of reverse proxy composition.

2. Composition by lazy loading the micro frontends bundled using JavaScript

This composition uses the vanilla JavaScript way to dynamically add a new script tag to load the micro frontend.

Container-based composition

Let’s apply this technique to two scenarios: 

2a. Each page is a different micro frontend

In this case, we need a container application that would be responsible to route to different pages and then each page internally can render the micro frontend. The same container app can also hold the layout for the overall app.

Using react-router, the container app routes for Catalog and Cart micro frontends would be:

---

---

and the catalog page component inside the container app can download and render the catalog micro frontend as:

---

---

The IF condition checking document.getElementById(‘app-catalog’) makes sure that the same micro frontend src isn’t downloaded when the user navigates back to the same page.

Inside the Catalog micro frontend, we have to make sure that we are exposing a method to render the micro frontend on the window object.

---

---

We can use the same code to render the different micro frontends on different routes or even create a library for that. Please check this github repo for the complete example of container based composition technique. 

2b. Multiple micro frontends in a single screen

Consider the example for a product details page where we can easily identify components from different domains rendered inside a single page.

Product Details Page

Using the same technique we discussed above, we can render the Review as a micro frontend inside the product details page directly instead of a route change.

Pros / Use Cases

• A pure JavaScript-based framework solution to compose micro frontend at run time.
• No full-page reloading as the whole application behaves like a seamless single-page app.
• No need for an additional server to route to the appropriate micro frontend.

Cons

• In the case of each screen as a different micro frontend, we need a container application that would render the micro frontend on route change.
• We will end up downloading duplicate dependencies for each micro frontend but it can be resolved using something like webpack externals and then using the script tag to download those dependencies from cdn.
• Since each micro frontend should run independently, we need two entry points in the configuration – one for the dev server and another for the production build to expose a method on the window object.

---

---

dev-root.js

---

---

index.js

---

---

Please check this github repo for the complete example of container based composition technique

It’s worth mentioning that one can also use iFrames or even web components to compose the micro frontends at run time, so long as cross microfrontend communication, authentication, performance, acessibility etc. requirements are taken care of. Always make sure you have understood the functional requirements before deciding on the composition pattern.

To understand which micro frontend communication technique can suit the composition patterns discussed above, check out the article on 5 different techniques for cross micro frontend communication.