Implementing the Multi-SPA Pattern for Microfrontends

Imagine you are an architect tasked with building the frontend for a large government ePortal that has and provides numerous online services for individuals and businesses. These services include registering for health benefits, submitting accounts for income tax, registering a small business, and paying vehicle road tax, in addition to publishing a whole bunch of informational content.

Or, scenario two, imagine you have been tasked to build a banking portal that provides multiple online services, from managing saving accounts to buying insurance, to investment opportunities, loans, mortgages, credit cards, and so on.

How would you go about planning not just your architecture but also the team that will be responsible for building it? Naturally, the first level of thinking would be to break down the large portal into multiple smaller modules or mini-apps and have each team focus on one of these mini-apps.

This would be...

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 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 16+ (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 VS Code 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 (I use 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...

Understanding the multi-SPA architecture

The multi-SPA architecture pattern is one of the most common patterns for building large-scale applications. As the name suggests, in this pattern, we have a collection of SPAs that together form a large application. In this pattern, each SPA behaves as its own independent feature or module that can be directly accessed via a URL namespaced and mapped to the app. These SPAs also share a very thin layer of shared components and global state to ensure coherency and consistency between the apps.

Figure 4.1 – The multi-SPA architecture

As you can see in Figure 4.1, we have four SPAs: a catalog, which will hold pages such as product listings, product details, search, and so on; a checkout SPA containing pages such as shopping cart, payments, and so on; the MyAccounts SPA; and the Seller/Admin SPA. You will also notice that this pattern allows us to easily add additional SPAs as the application grows.

Each of...

Building our Multi-SPA Microfrontend

Building a multi-SPA microfrontend essentially consists of three broad areas: breaking down the app into logical mini-apps, then we need to set up the routing between these mini-apps, and finally, we set up a global state the different mini-apps can read and write data to. Let us look at each of them in the subsequent sections.

Setting up our mini-apps

We will start with where we left off in the previous chapter.

In case you skipped the previous chapter and are directly jumping in here, you can start by cloning the repo from https://github.com/PacktPublishing/Building-Micro-Frontends-with-React/tree/main/ch3/my-mfe.

Let us quickly run pnpm install (if you haven’t already done so) and serve the respective apps to make sure that they are running properly.

Since we are going to build an e-commerce application, let us call our app eBuy. Feel free to rename your app folder to ebuy.

During active development, we would ideally...

Summary

This was a long chapter, so well done for staying with us until the end. We started off by looking at what the multi-SPA pattern looks like. We saw how this pattern would be most suitable for very large applications such as a banking portal, a government portal, or an e-commerce site. We saw the architecture pattern where all these different mini-apps can take advantage of a shared common library of components and utilities to ensure the consistency of the different apps.

We then took a deep dive into code and went about setting up our two mini-apps within the Nx monorepo, after which we went about creating our shared UI header component and used Semantic UI to build out our catalog and checkout apps. This was also a good opportunity for us to see how to use scoped names, which makes our import paths look clean and simple.

Then we went about setting up the routing so that we could navigate between the two different apps, and finally, we set up a custom hook to store our...