Implementing the Micro-Apps Pattern for Microfrontends

In the previous chapter, we saw the multi-SPA pattern for building microfrontends, which is ideal for building large-scale applications where each SPA contains its own user journey.

The primary advantage of this pattern is that each app is completely independent of the others, and they are connected via a namespaced primary route that is external to the app. As a user, while navigating through the app, you will have also noticed that when you move from one SPA to another, you are redirected via the browser and the page reloads. If this is something you’d like to avoid, and if you want a consistent SPA experience, then we can explore the micro-apps-pattern that uses Module Federation.

In this chapter, we will go about building a micro-apps microfrontend, where we will learn about the following:

• What is Module Federation, and why is it a key to building microfrontends?
• Setting up a microfrontend app with...

Technical requirements

As we go through the code examples in this chapter, we will need the following:

• A PC, Mac, or Linux desktop or laptop with at least 8 GB of RAM (16 GB preferred)
• An Intel chipset i5+ or a Mac M1 + chipset
• At least 256 GB of free hard disk storage

You will also need the following software installed on your computer:

• Node.js version 18+ (use nvm to manage different versions of Node.js if you have to)
• Terminal: iTerm2 with OhMyZsh (you will thank me later)
• IDE: We strongly recommend VS Code as we will be making use of some of the plugins that come with it for an improved developer experience
• NPM, Yarn, or PNPM. We recommend PNPM because it’s fast and storage-efficient
• Browser: Chrome, Microsoft Edge, or Firefox
• A basic understanding of Nx.dev monorepos and a basic understanding of using the NX console plugin in VS Code
• Working knowledge of React

The code files for this chapter can be found here...

Why do we need Module Federation for Microfrontends?

In the multi-SPA approach to microfrontends, you may have noticed that we end up duplicating some of the common dependencies across the different micro apps. In the grand scheme of things, when the primary goal is to keep things simple, this would be an acceptable trade-off. However, when the number of dependencies being duplicated and the number of apps being built are high, you need to optimize things and minimize duplication. Trying to achieve this before Webpack 5 would have led to having to deal with complex dependency management. It would also have made it difficult to maintain and evolve microfrontend applications. Module Federation helps us solve these challenges.

In the next sections, we will learn more about what Module Federation is and how it helps with building microfrontends.

What is Module Federation?

Module Federation is a new feature introduced in Webpack 5 that allows us to load external JS bundles in real time.

Before Module Federation, the standard way to import all the necessary modules for an application was only during build time, where it created a large JS bundle or smaller chunks that got loaded based on page routes, but it wasn’t quite possible to dynamically load an app bundle in real time.

Module Federation provides us with a radically new way to architect our apps, build and deploy shared components, and update them without the need to rebuild the entire application.

Traditionally, we build most of our shared components, such as UI component libraries or npm modules, and import them into our application during build time. With Module Federation, these modules can be hosted at an independent URL and imported into the application at runtime. We take advantage of this very same feature to build our microfrontend architecture...

Setting up Microfrontends with a Host and Remote app

We are going to take our multi-SPA app and convert it into a microfrontend with a Host and Remote app using Module Federation. As mentioned earlier, the main benefit of this approach is that users get a true single-page experience while still ensuring that each app is independently built and deployed.

Let us see what it takes for us to do this:

Figure 5.2 – Module Federation setup

You will notice that Figure 5.2 is similar to Figure 5.1 and explains the implementation details of Module Federation. We see that the Host app contains the header component and runs on port 4200. We then have our Catalog and Checkout apps running on ports 4202 and 4201. We aim to load these remote apps dynamically whenever the correct route is called.

To convert our multi-SPA into a module-federated microfrontend, we will need to make the following changes:

1. Create a new Host app that we’ll call...

Extending Module Federation to a true Micro-apps Pattern

Imagine you are part of a team that manages a very large e-Commerce app (think of Amazon.com). For such large sites, it is a common practice to have teams that own a single organism-level component (https://atomicdesign.bradfrost.com/chapter-2/#organisms) instead of the entire mini app.

For example, we have a dedicated team that works exclusively on the Product Recommendations component. This component is injected into, say, the Catalog app.

In such a case, it would be prudent to create another micro app called Recommendations and dynamically import it into the Catalog app. This would allow for true, federated, micro-app pattern architecture.

Figure 5.5 – Tree of remote apps with Module Federation

As you can see from the preceding diagram, we can further break down our Catalog and Checkout apps into smaller organism-level components and have each of them load into the Catalog app remotely...

State management with Module Federation

As you may have noticed by now, our custom state management system, which uses sessionStorage, continues to work seamlessly with Module Federation. This is because, from a React perspective, it all looks like a regular React application, with modules being lazy-loaded. So, one of the benefits of Module Federation is that we can use any of the regular state management concepts, such as prop drilling, context API, or libraries such as Redux or Zustand, to manage the state.

In this section, we will make use of the Zustand state management library as it is extremely user-friendly and has zero boilerplate code.

Now, logically, especially for those who use a lot of context API, we would be inclined to have the store within App-shell and have the other micro apps consume it. However, with Module Federation, this would not be ideal, because the store would need to be exposed as a remote app and imported into other micro apps that act as hosts....

Summary

We’ve finally come to the end of another interesting chapter. We started by learning about Module Federation and how it is a game-changer in the way we build and maintain apps. We learned some of the basic concepts of Module Federation, such as host apps, remote apps, remoteEntry, and more.

We then saw how to convert our multi-SPA app into a module-federated app with an app shell and how to load the Catalog and Checkout apps as remote apps. Then, we further broke things down to include smaller micro apps within these apps to create a tree of module-federated micro apps. Finally, we saw some of the best practices of managing the state and saw how we can look at tools such as Zustand to manage the state between these different micro apps.

In the next chapters, we will see how to build these apps for production and how to deploy them to static storage on the cloud.