DEV Community: Antonio Lagrotteria

A complete AWS Architecture for Module-federated micro-frontends

Antonio Lagrotteria — Fri, 24 Dec 2021 15:21:52 +0000

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:

Mono-repo code changes triggering specific deployment pipelines.
Deployment pipelines building and deploying bundle artifacts to target AWS resources.
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 ;)

A “Find Corona Test Centers” PWA powered by Amplify Geo and Location Search

Antonio Lagrotteria — Tue, 30 Nov 2021 16:14:38 +0000

Given the recent sad increase of Corona cases in Denmark and my involvement in the Frontend and Serverless cohorts in the AWS Community Builders, I decided to combine the two topics by creating a React application (web-based but also being a Progressive Web App) aiming at searching for Covid19 test centers in Denmark.

I will use Amplify Geo, which adds location-aware features to web applications and Amazon Location Service, which provide secure, reliable and high-quality geospatial data from established global providers such as Esri and Here.com.

Data is available via Rest API from Coronasmitte and CphMed, two very valuable web sites where to find centers information too.

Finally, the app will be deployed on a CloudFront distribution linked with a S3 origin. You can browse the web-app here.

Prerequisites

This article assumes that you:

know how to create a Progressive React app via Create React App tool
know how to configure and initialize Amplify in the project
get familiar wit the Geo’s Getting Started guide

App use cases

Users of this application will be able to:

Navigate an interactive Geo map with locations and group of locations (aka clusters), with ability to search for locations via an address bar, and getting suggestions via the Location Search service.

Access to valuable Test center information such as address, opening hours, waiting time, type (Antigen or PCR) and more when clicking on the specific location — which in turns open a popup.

Amplify Geo main components

The Getting Started guide is pretty comprehensive so I will not repeat much of the steps in this article. Instead let’s look at two main components in Amplify Geo: Maps and Location Search.

Maps

Based on the MapLibre GL library, Amplify Geo Maps visualize interactive vector maps on the web mostly by abstracting its usage via the maplibre-gl-js-amplify package, which exposes, among others, two very important methods:

createMap, very self-explanatory method initializing the map default properties such as zoom level, center of the map, etc.
drawPoints, which, given the coordinates, organizes them into clusters (groups of locations) and unclustered (markers indicating a specific test centre) options, used to modify the look and feel of the elements in the map.

Full code can be found in GitHub. Below snippet shows the implementations of above methods.

Location Search

Location Search enables search of locations such as addresses, cities by using Esri or Here Geo Location platforms behind the scenes. By combining it with a couple of React components (AutoSuggest and DebounceInput — Github code here), users are able to input a text, which eventually pops a series of suggestions found by the Location Search via the Geo.searchByText method.

Progressive Web App Gotchas

At the time of the writing the PWA can be installed on Chrome Desktop and Android (via three dots menu and Install App item). For IOS you can manually add the app to home screen manually, obtaining something like below:

Assess app security and performance

WebPageTest is an established web site that can be used to measure the security and performance of your web page. After initial screening, it was clear that some actions needed to be done:

Control-cache headers should be set to S3 buckets for caching purposes, by adding metadata to all objects in bucket by editing and Add Metadata option:

Create a Custom Policy adding security related headers, thanks to a recent release under Policies -> Response Headers

Edit distribution Behaviour by associating a Cache Policy and a Response Headers policy we just created.

After above changes we went from a full blood report to a much nicer view:

Above were not part of the default Amplify add hosting command, but recent releases about custom resources, export and override can help in automating that via a CDK stack.

Summary

Amplify Geo makes extremely easy and quick to setup up a secure and scalable map functionality and infrastructure in hours.

In regards of PWA area I may add in future a component which can popup the installation process proactively.

As I am still in Free Tier zone, I am also very interested in keeping an eye on pricing and will definitely update this section if something worth mentioning pops up.

References

https://docs.amplify.aws/lib/geo/getting-started/q/platform/js

AppSync Lambda authorizers via new Amplify Custom Resources

Antonio Lagrotteria — Thu, 18 Nov 2021 15:56:36 +0000

Amplify and AppSync allow customers to consume a fully managed GraphQL API endpoint in minutes and gracefully handle authorization. This article shows how you can leverage the newly recently introduced AWS Custom Resources to add the new AWS Lambda authorization mode via CDK. We will integrate this endpoint with a very simple React web-app.

Fun fact

The first version of this article was based on independently provision the needed AWS resources via CDK, on its own folder/project. Nevertheless in the AWS Community Builders Slack channel, I came to know that a related feature was being released by the AWS Amplify team which brought me to revisit the article with slightly different but cleaner implementation. This synthetizes the awesomeness of the program. You can find the before and after custom resources implementation in GitHub.

Add Custom resources

With latest Amplify now you can add custom resources by defining CDK stacks. A typical approach before this was to separate your CDK into a cdk or infra folder within your project. Now you can have it within the Amplify backend. Issues the below commands:

npm i -g @aws-amplify/cli
amplify add custom

Currently you can define custom resources by either CDK or CloudFormation templates, we will opt for the first choice and provide a name for the custom Resource e.g. lambdaAuthorizerCustomResource. This generates a skeleton CDK stack under the amplify/backend/custom/ path.

Before we modify the pre-generated cdk-stack.ts file and create a cdk.ts, let’s look at the content of the CDK stack in the next section.

Provision GraphQL via CDK

Being a huge fan of Infrastructure as Code principle, I decided to create the GraphQL endpoint by using AWS CDK for Typescript language. Essentially, CDK abstracts CloudFormation stacks in a programmatic way. Below stack will provision:

an AppSync GraphQL endpoint based on a schema.graphql defining the model and a Lambda authorizer configuration.
An Authorizer Lambda function with its necessary IAM policies.
A business-related Payments Lambda function containing CRUD operation on as on a defined model (here the Payment model) via its GraphQL resolvers. This Lambda is attached as a datasource to AppSync.
A DynamoDB table to persist the models.

Full code, outputting the GraphQL endpoint, can be found here.

It is important to note that now you can use Amplify project metadata such as project and environment name to define your resources at run-time.

At the time of the writing I had to create a cdk.ts file in order to initialize the stack and associate it with the app:

Finally, let’s build and deploy the changes:

amplify build
cdk deploy --app "npx ts-node cdk.ts" --parameters env=dev

Above steps could be manually performed AWS Console, but just with more steps and error-prone risk. Here below we show the visual output of the CDK:

Lens on Lambdas

We have provisioned two Lambda functions: one “glueing” AppSync with DynamoDB as datasource and one performing authorization checks. IMPORTANT: Notice they have been prefixed with the data coming from our CDK stack: authorizerappdev.

Datasource Lambda

The Datasource Lambda leverages AWS SDK to perform CRUD actions on DynamoDB table. Below snippet showcases listing of payments, the rest can be looked at Github repo.

Authorizer Lambda

AppSync forwards any client requests to this function, by providing an authentication token. For this PoC, I leverage an RSA key pair to verify the payload of an incoming JWT token and its signing via a public key previously generated. This is done by using the jsonwebtoken package.

At this stage we just need a client consuming the GraphQL endpoint, so let’s look at it in details in the next section.

Integration with Amplify

At the time of the writing (November 2021), the new Lambda authorizer is not yet available via Amplify CLI. This entails that we need to setup a manual integration with AppSync, which though is very simple.

Assuming you have configured and initiated Amplify in your project, All you need to do is to manually add this snippet as part of the Amplify configure method, usually located in your App.js/ts file — if using React.

To demonstrate the JWT verification, I have created a very dumb React UI.

A JWT token gets generated by calling a local FastifyNodeJs server exposing a generate-token endpoint. Details can be found here. The endpoint uses a private key in order to sign the generated JWT token, which then will be verified, as shown earlier, by the Lambda Authorizer function. In this case we just send a naïve foo/bar payload, but in real life must be much more complex and following Oauth claims more strictly. The call is performed by calling the API endpoint and providing a GraphQL query and the JWT token.

Summary

Lambda authorizers and Custom Resources are yet another weapon to the Amplify and AppSync arsenal, opening for a myriad of use cases and combinations of single and multiple authorizers and third-party integrations. This article is intended as a starting point for customers to start using the Lambda Authorizer feature and just showed a very simple implementation which can then be extended for more further refinement.

References

AWS AppSync now supports custom authorization with AWS Lambda for GraphQL APIs
Building Scalable GraphQL APIs on AWS with CDK, TypeScript, AWS AppSync, Amazon DynamoDB, and AWS…

A server-less CI/CD approach for mono-repo micro-frontends

Antonio Lagrotteria — Sat, 06 Nov 2021 13:39:33 +0000

This article provides a CI/CD pipeline approach for a GitHub mono-repo-based micro-frontend architecture in AWS, leveraging a series of AWS server-less services such as AWS CodePipeline, CodeBuild and CodeDeploy.

Micro-frontends come with an increase of the complexity of managing the infrastructure, which makes it crucial for organizations to carefully invest their time in supporting continuous integration (CI), continuous deployment (CD) pipelines and automatic tools that scale along with the organization.

The proposed approach provides a scalable option for organizations to scale their tech micro-frontend ecosystem, keep teams autonomous and let them focus on business and early feedback with a fast release cycle.

Some context: Mono and Poly repos

Before diving in the architecture, let’s mention the main approaches for structuring a micro-frontend module.

Mono repos: all the teams work on a single repository
Poly (multi)-repos: each domain specific micro-frontend is located in its own repository and owned by a single team.

This PoC will focus on a hands-on, detailed and pragmatic CI/CD setup based on a mono-repo with main branch as source of the pipelines changes. For a great overview and detailed comparison I recommend an upcoming book from Luca Mezzalira.

Architecture

The architecture is based on a scenario where a company is implementing micro-frontends on a mono GitHub repository and wishes to implement a server-less CI/CD pipeline in AWS.

For this PoC, the mono-repo contains two trivial Angular micro-frontends, mfe-accounts and mfe-payments, though this model allows you to write each module independently with any framework of choice:

The scenario involves some steps:

Developers push their code to the main branch in GitHub, which will trigger a push event via GitHub webhooks to an AWS API Gateway responsible to handle the event.
The API Gateway triggers an AWS Lambda function which authenticates the request, analyses the event and, based on affected files, triggers a pipeline for the micro-frontend where the files belong to.
One or more pipelines start building, testing and deployment actions via AWS CodePipeline, CodeBuild and CodeDeploy.
Changes are available in S3 bucket and exposed on a Cloudfront distribution.

Lets deep dive in the setup.

API gateway setup

GitHub allows to setup integrations towards its events, such as repository pushes, via webhooks, which POST a GitHub event data payload towards an endpoint. Let’s expose a RESTful API in AWS via API Gateway containing a single POST endpoints as shown below:

In above screen, we use a Lambda integration proxy because our associated “Hello World” Lambda will need to access the API Gateway request headers in order to authenticate GitHub upcoming requests. With the API in place, let’s create the webhook.

GitHub Webhook setup

Once the API Gateway has been deployed in a stage, it is time to create a GitHub webhook, (refer to this intuitive guide). Important: provide a secret to make sure that our Lambda can accept requests only coming from the webhook (more on this later).

The integration is ready! Pushing a file to the repository will result in a “Hello world” message triggered by the Lambda, which can be seen under its stream logs in Cloudwatch. Let’s now update Lambda code to make sure that we support CI/CD for any micro-frontends in your repo.

Micro-frontend strategy on Lambda setup

The ultimate goal of the Lambda function is that given a GitHub push event containing repo commits, then it triggers one or more pipelines for any affected micro-frontend. Let’s look in details at below gist:

First, Lambda authenticates requests only coming from the GitHub webhook by validating the SHA256 request header via a HMAC256 security check, using the crypto module. This check is based on the secret defined in the GitHub webhook earlier and also stored in AWS Secret Manager (follow this tutorial). Lambda will access the secret in a secure way via the IAM action secretsmanager:GetSecretValue
Once validated, the payload is used to infer which micro-frontends have been affected, by extracting its name from the added/modified and removed files from the commits list.
If any micro-frontend has changed, we trigger a new build in AWS CodePipeline which will build and deploy the micro-frontend. For simplicity the pipeline is called the same as the micro-frontend which is going to build. The AWS SDK client library requires an IAM role allowing codepipeline:StartPipelineExecution action to access the resource

Overall Lambda code can be seen here. Now it is time to create the pipeline itself, which is part of the next section.

Code Pipeline setup

The creation of a Code Pipeline in AWS involves many steps and concepts, so I will try to keep it simple. Code Pipeline helps to automate release pipelines for fast and reliable application and infrastructure updates. Each steps, here called stages, perform actions on the involved build artifacts. I will look into how:

Create the pipeline by choosing some settings
Add a Source stage, answering the question “from where does the code to build come from?”
Add a Build stage: “how do I build the source code you just provided?”
Add a Deploy stage: “how and where do I deploy the build artifact you just provided?”

The main idea will be to isolate each CodePipeline and CodeBuild project to give flexibility and ownership to each team to manage that process within the team. Optimizations such as reuse of pipelines for similar projects and CloudFormation template are out of scope.

Create pipeline by choosing settings

First, create a pipeline by providing a name matching the building micro-frontend and default settings, as shown below.

Source Stage

This stage links the source code to be processed with Code Pipeline. We will connect CodePipeline with our GitHub repo by clicking the Connect button and initiating a wizard.

At the end of the wizard, as shown below, you will be able:

to access your GitHub repo (aladevlearning/microfrontends-pipeline in my case)
to select the *main *branch
to unselect the Start pipeline on source code changes, as we want to have it handled by the Lambda function
and click Next to proceed to the next stage.

Above steps can be seen in below gif.

Build Stage

This stage is responsible to build the source received in previous stage. It will create or reuse an existing *CodeBuild *project, which instructs the pipeline on:

how to run the build, via a builspec.yml file.
where CodeBuild will practically make the build

In regards to buildspec.yml we can decide whether having a common file for all micro-frontends or having one for each of them. This highly depends on whether all micro-frontends adhere to same framework of choice and same build / test steps. By keeping them separate you give each team independence on how to build it, at the cost of slightly more complex overview on build process and governance. For our micro-frontend, the file looks like below:

A buildspec.yaml consists of intuitive phases for installing/prepping the environment, building the code and instructing how to structure the artifacts. After getting the micro-frontend name from the pipeline initiator, the file installs dependencies and zips the final artifact, which will be deployed to S3 bucket specified in the Deploy section. See this guide for more details.

Finally, the building process requires an environment (aka: machine) where to run.

Above gif shows how CodeBuild configuration is based on a build environment, *which represents a combination of operating system, programming language runtime, and tools that are used to run a build. We also selected a specific *buildspec.yml file location as each micro-frontend could differ in terms of build process and pipeline (e.g. one could be an Angular project and another be a React one, or both still using same framework but being built with different steps).

Once the Code build project is setup, we set the build provider to be Code Build, we select the newly created Code Build project (mfe-accounts-build) and continue to the final stage.

Build project created, let’s move to the final stage of CodePipeline.

Deploy Stage

Finally, we want to deploy our artifact on S3. In order to do that, we need to create S3 buckets where the artifact will be independently deployed. As CodeBuild will zip the built artifact, we check the Extract file before deploy *settings and set the *Canned ACL to public-read, given we want to be able to see the deployed artifacts in S3.

That’s great! Your code is now deployed in S3 which allows to associate it with a CloudFront distribution for better deployment. Above steps for the CodePipeline should be repeated for any micro-frontend. This level of redundancy will allow each team to be independent and autonomous, tweak their CI/CD to

Result

Upon push to repository affecting the micro-frontend containing the change, one or more code pipelines will start.

Successful pipelines will look like this:

The deployed artifact is located under the specified S3 bucket:

Associated with a Cloudfront distribution, our deployed micro-frontend will look as this:

Full code can be found here.

Summary and ideas

This article went in depth to provide a 10 minutes setup to make a seamless CI/CD pipeline for a mono-repo based frontend architecture. This should be seen as a workable, though initial approach which can be explored in so many ways, proving yet again how great and creative is to build things in AWS. Some ideas could be:

Have different pipelines to cover different needs, such as different framework, test suite, integration and functional testing, multi stage environment, etc…
publish artifacts in different AWS Accounts, one for test and one for production, to keep isolation and security in place.
Extend approach for feature branch CI/CD, where you could created branch deployments for early prototyping and feedback, without blocking the main branch.
Make the above as a CloudFormation template. This is a must to elevate this approach and consistently repeat it for any micro-frontend.
CloudFront invalidation step. If interested in adding CloudFront in the pipeline, a cache invalidation step via a Lambda function may be necessary to make sure all latest changes are correctly propagated to the consumers (or maybe AWS will take it as feedback and expose it as this seems a pretty used pattern).

References

Complete CI/CD with AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline | Amazon Web…
Building Micro-Frontends: the book