A complete AWS Architecture for Module-federated micro-frontends
Tags: aws, microfrontends, javascript
Published: 2021-12-24 15:21:52

**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](https://webpack.js.org/concepts/module-federation/) plugin and [Lerna](https://github.com/lerna/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

![High level architecture](https://cdn-images-1.medium.com/max/3342/1*T_OrAE8h81-7u_2x5DWJIw.png)

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:

![Mono-repo structure](https://cdn-images-1.medium.com/max/2000/1*WJ7j1CvzaZ9Dn5CNY4doPQ.png)

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.
{% gist https://gist.github.com/aladevlearning/6d0ef5bbe06c1654cfa8b6d9fab11539.js %}
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.

![Mono-repo triggers from GitHub](https://cdn-images-1.medium.com/max/2000/1*8bLIHFGWteY4F7u_OJsafA.png)

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](https://docs.github.com/en/developers/webhooks-and-events/webhooks/about-webhooks), 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](https://levelup.gitconnected.com/a-server-less-ci-cd-approach-for-mono-rep-micro-frontends-e91261bbdf69), 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.

![Deployment CI/CD](https://cdn-images-1.medium.com/max/2000/1*vQTICQ0SDtJg4VKNL4PAeg.png)

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.

![Hosting infrastructure with S3 and Cloudfront](https://cdn-images-1.medium.com/max/2000/1*zK1QOLn0giIQ_85rkUEUAw.png)

With above sub-architecture, end-users will access the web application via a CloudFront distribution [protected by WAF](https://aws.amazon.com/waf/) , given the micro-frontends are customer-facing optimized applications. CloudFront connects to the private S3 bucket via an [OAI ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)identity, ensuring data is publicly accessible only via the CDN and not directly from the bucket. CloudFront uses a [Lambda@Edge](https://aws.amazon.com/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 ;)