A complete AWS Architecture for Module-federated micro-frontends

Hi, click “Follow me” button on Medium to stay tuned for more articles in this area ;)

Original article: https://levelup.gitconnected.com/a-complete-aws-architecture-for-module-federated-micro-frontends-a0306ba466e3

My next series of articles presents a complete server-less architecture aiming at deploying and hosting client-side mono-repo micro-frontends on AWS, based on Webpack Module Federation plugin and Lerna.

All AWS resources will be provisioned via CDK, meaning that in a matter of minutes, you will get a production-ready, reliable, and scalable infrastructure deployed to your AWS account, allowing your teams to scale independently and deliver fast business iterations via their independent micro-frontends.

The Architecture

The architecture consists of 3 main parts:

1. Mono-repo code changes triggering specific deployment pipelines.

2. Deployment pipelines building and deploying bundle artifacts to target AWS resources.

3. Globally scalable hosting infrastructure tailored for client-side micro-frontends.

A bit on Mono-repo setup

Micro-frontends are part of a mono-repo setup, aka a single repository with sub folders including independent web apps, glued together through the Webpack Module Federation plugin and Lerna. A sneak peek of repo structure can be seen below:

If you are impatient, you can see how micro-frontends are represented via Module Federation systems in the below gist, which will be discussed in detail in near future.

In a nutshell, the above code allows us to model micro-frontends as systems which can be lazily loaded as Web components in your app. The trick is to dynamically inject each micro-frontend script in the app page so that they can be remotely loaded by the host /shell app. As said, more to come in the upcoming article. For now, we will look at the 3 sub-architectures mentioned early.

Mono-repo triggers

The goal of this first step is to capture individual micro-frontend repos changes and trigger them for later use by server-less components.

Developers push the changes to their belonging micro-frontend via Github, though the same can be accomplished for other well known versioning source platforms such as BitBucket. Via a Github webhook, changes are handled by a Lambda function exposed as Restful api via an ApiGateway. Main goal of Lambda is to associate the micro-frontend code change with their destination pipeline. A manual walkthrough of this approach can be appreciated here, while its CDK implementation will be part of the next article.

Deployment pipeline

The goal of the second step is to make sure that individual micro-frontend repo changes trigger individual code pipelines. This encourages team independence as if only a micro-frontend is modified (e.g.: mfe-app1), we only want to trigger its related pipeline, and not all the others.

Once a code change is associated, an AWS Code Pipeline gets started. This includes four main steps:

• The Code Pipeline itself, which manages the GitHub connection and fetches the associated GitHub source code

• The Code Build, which builds the receiving source code into a build artifact. As micro-frontends are JavaScript based, they will leverage yarn to build them into a set of bundles to be used in the next step.

• The Code Deploy. This step takes the built bundled files from previous steps and deploys them to a single Simple Storage Service (S3). Each micro-frontend will be stored in an independent “folder” (or key), so that they can be deployed individually.

• The Code Build Cache Invalidation. The last step is yet another Code Build step which ensures that CloudFront cache gets invalidated every time we publish and deploy new artifacts on S3.

Hosting infrastructure

Last but not least, foundational AWS resources need to be provisioned. The goal of this last step is to make sure this happens with a scalable, simple yet smart and reliable architecture.

With above sub-architecture, end-users will access the web application via a CloudFront distribution protected by WAF , given the micro-frontends are customer-facing optimized applications. CloudFront connects to the private S3 bucket via an OAI identity, ensuring data is publicly accessible only via the CDN and not directly from the bucket. CloudFront uses a Lambda@Edge function for proper dispatching towards different origins coming from the single bucket.

CDK to rule them all

All above will be provisioned via a CDK application which includes three stacks:

• The foundation stack. This provisions the foundational AWS resources used to host the app including S3 bucket, a Lambda@Edge function, a CloudFront distribution and various IAM policies, roles and OAI to support correct privacy and security.

• The second stack is an implicit one because it gets created when provisioning the Lambda@Edge function via the CDK Experimental CloudFront API, as it has to deploy the Lambda@Edge on a specific AWS region (us-east-1 is used by default for all edge functions).

• The ci/cd deploymemt stack. Its job is to provision all AWS resources associated to ApiGateway and the Code Pipeline.

Summary

This article leaves intentionally a cliffhanger feeling as there is a lot to cover. It gives an high level overview of a de-facto server-less AWS architecture for hosting and deploying mono-repo micro-frontends based on Module Federation Webpack plugin. Following articles will deep dive in how this was achieved, so better stay tuned ;)