Deploying Microfrontends to Static Storage

Things start to get interesting from this chapter on, because we are now stepping out of the frontend/React world and moving into the areas of cloud and full life cycle engineering.

As you may recollect from earlier chapters of this book, one of the primary goals of a microfrontend architecture is to ensure that we don’t need to deploy the entire application each time a small change is made but instead only deploy the micro apps that have changed. Hence, a book on microfrontends wouldn’t be deemed complete unless we covered the critical topic of deploying our microfrontend to production in the right way.

When it comes to deploying SPAs, usually we run the webpack build command to generate our JavaScript bundles and assets in the /build or /dist folder, which we then simply copy to a static website hosting provider to make our app available to our users. However, deploying microfrontends is a bit more complex.

In this...

Technical requirements

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

• A PC, Mac, or Linux desktop/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 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 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, Firefox
• A basic understanding of Nx.dev monorepos
• A basic understanding of Firebase and static site hosting would be helpful

The code files for this chapter can be found here:

https://github.com/PacktPublishing...

What is Static Storage?

Cloud hosting providers such as AWS, Google, and Azure offer a variety of hosting solutions. Static storage, also known as blob storage, refers to a type of storage service that is optimized for storing large amounts of unstructured data, such as Binary Large Objects (Blob). This data can be of any type, including images, videos, audio files, and text file formats such as HTML, CSS, and JavaScript.

Static storage is designed to be highly scalable and is usually served via a Content Delivery Network (CDN). This allows it to handle large volumes of data without performance degradation, and also makes it highly durable, with data replication across different nodes to ensure that data is not lost due to hardware failures or other disruptions.

A key point to keep in mind about static storage is that it doesn’t have any compute power; that is, it doesn’t have any CPU or RAM resources. It can only serve static files. Think of it like a very large...

Setting up Firebase

Firebase, which is part of Google Cloud Platform, is an extremely easy-to-use and developer-friendly hosting provider. Firebase has a lot of offerings and services for building and managing web and mobile applications.

Many of these services have free tiers, which make it ideal for building and testing things out. You can access all the products and services by heading over to www.firebase.com and logging in with your Google account.

Once you’ve logged in to Firebase, head over to Manage Console (https://console.firebase.google.com/).

Create a new project. Let's call it ebuy. In the next section, we will set up our sites within this project.

Setting up a project with multiple sites

We will be using Firebase’s hosting service to deploy our apps. If you are not familiar with Firebase Hosting, we strongly encourage you to head over to https://firebase.google.com/docs/hosting and read about it:

1. Once in the console, select the...

Creating the Microfrontend Production build

As you may recollect, so far, we’ve only run and tested our microfrontends in development mode, using the nx serve command. For us to deploy applications to a hosting server, they need to be built in production mode.

This is usually quite straightforward in regular React apps, but with our microfrontends, it needs a bit more work.

Open up the ebuy app we built in Chapter 5 and follow these steps. Let's first create a script command to build all our apps:

1. Open up the package.json file on the root and just like the serve:all command, let's create a new command for build:all as follows:

   "build:all": "nx run-many --target=build"

2. Run the pnpm build:all command and let us see whether all the apps build. Oops! You’ll notice while all the other apps built fine, app-shell threw out some error about not being able to find catalog/Module or checkout/Module, and so on.

   Let's dig a bit into...

Deploying our Apps to Firebase

Deploying our apps to Firebase is quite easy using the Firebase CLI’s deploy command. However, before we run our Firebase deploy command, we need to let Firebase know which micro-apps go into the corresponding Firebase website. We do this in the /firebase.json file.

Replace the default configuration with the following:

 {
  "hosting": [
    {
      "target": "app-shell",
      "public": "dist/apps/app-shell",
      "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
      "rewrites": [
        {
          "source": "**",
          ...

Deploying only Micro Apps that changed

To be able to deploy only the micro apps that have been impacted by modifications to a file, we basically need to be able to do two things:

1. Identify which apps have been impacted due to changes to a given set of files
2. Only build and deploy the micro-apps that have been impacted

For the second point, from the previous section, we now know how to let the Firebase CLI know which micro-app we would like to be deployed. We will look at how to achieve the first point in the next subsection.

NX Affected

The NX dev tools come with a handy command called nx affected, which is able to keep track of what files changed from the previous commit and highlight the apps that have been impacted due to the changes to these files.

This is a nifty feature that can be used for various purposes, such as speeding up the execution of tests by running unit tests or build commands only against projects that have been impacted by changes to certain...

Summary

With that, we come to the end of this chapter, where we learned about static storage hosting and why it is ideal for deploying and serving client-side-rendered React apps. We saw how to build production bundles for our module-federated micro app. We then saw how to set up a multi-site project in Firebase and used Firebase CLI commands to deploy our apps. We also saw how to address CORS issues by setting the right header values for the Access-Control-Allow-Origin header, and then finally, we saw how to combine the nx affected command and Firebase’s hosting:<app-name> command to detect the micro-apps that have been impacted by a change and only build and deploy them to Firebase. We also used this as an opportunity to create a custom command executor to deploy these affected apps.

In the next chapter, we will go deeper into DevOps and cloud territory by seeing how to deploy our microfrontends to a managed Kubernetes cluster.