Using AWS Serverless Technologies to Host and Serve Microfrontends.
Developing Microfrontends for web applications is slowly getting traction nowadays. As we all know, keeping frontends small as Microsfrontends has its ups and downs. Besides, managing their lifecycles and deployments are among the everyday challenges.
But have you ever considered using Serverless technologies to overcome some of these challenges?
In this article, I will walk you through using AWS serverless technologies to host and serve your Microfrontends.
As a little side-note: To keep UI consistent over different microfrontends and to save development time, I recommend you share and reuse UI components using tools like Bit (Github). Hopefully, I will address this subject in greater detail in future posts.
sharing reusable UI components with bit.dev
Hosting Microfrontends
Hosting Microfrontends in Amazon S3
In contrast to using containers for your Microfrontends, the best alternative in AWS is to use Amazon Simple Storage Service (S3). Using Amazon S3, you can store all your frontend static assets, including HTML, JavaScript, CSS, Fonts &, etc. One of the main advantages of using Amazon S3 is that the underlying infrastructure provides 99.99% for high availability for serving your Microfrontends by default.
But there is one common limitation. That is, you can only host static Microfrontend artifacts (No server-side rendering) in Amazon S3.
However, it suits most of the modern frontend frameworks like Angular, ReactJS, VueJS, which we use to build Microfrontends.
Tips for using Amazon S3 for Microfrontends
Let’s look at a few tips that will help you when hosting Microfrontends in Amazon S3.
- Use separate buckets for each Microfrontend — Doing this will help you to keep each Microfrontend lifecycle in isolation with each other. It will also allow you to grant access permissions for each team with increased granularity.
- Don’t serve the Microfrontends directly using Static Site Hosting — When serving the Microfrontends from Amazon S3, using Static Site Hosting will expose your frontend to the public without any added controls like geographical restrictions. Besides, it will force you to use cross-origin request sharing (CORS) without exposing the entire application using a single domain.
- Keep dynamically uploaded artifacts separately from Amazon S3 buckets that host Microfronends — Use separate Amazon S3 buckets for file uploads from the web application, besides using the ones allocated for Microfrontends.
- Use separate buckets for versions — When deploying Microfrontends, backup each deployment package in a separate bucket. Keeping a backup version of the deployment artifacts will allow you to rollback or deploy a previous version if anything goes wrong. However, using the inbuilt Amazon S3 versioning feature might complicate the things for Microfrontends since each file in the bucket is versioned separately.
Serving and Caching Microfrontends
Routing and Caching for Microfrontends
Amazon CloudFront is one of the core services that plays several roles when serving Microfrotends for the outside world. One of the apparent features we get by default is the Content Delivery Network (CDN) capabilities to cache the Microfrontends closer to the end-users. Besides, Amazon CloudFront also provides the gateway capabilities to route requests to different Microfrontends. This feature is quite useful since we can route both Microfrontend and Microservice requests in one place, eliminating the need for separate gateway services.
Useful features in Amazon CloudFront for Microfrontends
Let’s look at all the capabilities Amazon CloudFront can fulfill relevant to Microfrontends.
- Content Delivery Network (CDN) — Allow caching the static assets closer to the end-users, speeding up the Microfrontend loading.
- Gateway and Routing — Route configuration to route requests coming from browser depending on the URLs (Advance routing possible using Lambda@Edge)
- SSL Termination — Single point for external access allowing the setup of free SSL certificates using AWS Certificate Manager as well as the SSL termination.
- Web Security Firewall — Provides the capabilities to connect a web application firewall with minimal configuration for security.
- Create Dynamic HTML — Allows adding dynamic content for Microfrontends using Amazon Lambda@Edge. For example, you can modify the HTML served through Amazon CloudFront by writing some code.
- High Available Content Delivery — Provides geographical redundancy serving the Microfrontends with high availability.
Deployment Lifecycle of Microfrontends
When using Amazon S3 and CloudFront together, you need to consider invalidating the CloudFront cache for each deployment, unless you generate new filenames for each new deployment package.
If needed, invalidating the CloudFront cache is possible by using CloudFront CLI commands. These commands you can execute in the build pipeline for new deployments.
Besides, it is essential to consider managing the high availability of the Microfrontneds when doing a deployment. For instance, let’s consider the following two sequences we can use for the deployments.
- Add a new files -> Invalidate CloudFront cache -> Delete the old files
- Delete the old files -> Add new files -> Invalidate CloudFront cache
In this particular scenario, the first sequence is preferred over the second, considering that the latter sequence has the possibility of downtime if a client accesses the Microfrontend in the middle of a deployment. Though it is likely to have a CloudFront cache hit in the latter scenario eliminating the downtime, it is better not fully dependent on it.
Suggest:
☞ Using Python to Automate AWS Services | Lambda and EC2
☞ How to Install and Host Wordpress Website on Shared Web Hosting (Hindi)
☞ Easily Deploy to Vercel with One Click
☞ Host Vue JS Project on Shared Web Hosting (Hindi)
☞ Serverless Authentication with AWS Amplify and Vuex
☞ Deploy AWS EC2 Instances whenever your Job Queue Backs up | DevOps Event Remediation