Building a Monorepo MFE with Nx and AWS CloudFront + S3

Introduction​

Micro Frontend (MFE) architecture has become a popular approach for scaling frontend applications. By splitting the frontend into independent modules, teams can work on different parts of the app simultaneously. In this blog, I'll walk you through how I built a monorepo MFE using Nx, AWS S3, and CloudFront.

This setup consists of:

• Shell App (Host application)
• Shop App (Remote MFE in a separate repo as a Git submodule)
• About App (Remote MFE in the main monorepo)

I'll cover how to:

1. Scaffold an Nx-based MFE project
2. Configure Git submodules for the remote shop app
3. Build and deploy the apps to an AWS S3 bucket & CloudFront

Architecture​

Overall MFE architecture:​

MFE Git repository structure:​

Step 1: Setting Up an Nx Monorepo​

First, create a new Nx workspace configured for an Angular MFE setup:

npx create-nx-workspace nx-monorepo-mfe --preset=apps
cd nx-monorepo-mfe

Add the MFE Module Federation plugin:

nx add @nx/angular

Now, generate the shell and remote apps:

nx g @nx/angular:host apps/shell

nx g @nx/angular:remote apps/about --host=shell

The shell app serves as the main host, dynamically loading remote apps (about and shop).

Step 2: Add a Remote App about​

Let's generate our first remote app for the About page:

nx g @nx/angular:remote apps/about --host=shell

Verify that it is registered in the shell's module-fedration.config.ts.

const config: ModuleFederationConfig = {
  name: 'shell',
  remotes: ['shop', 'about'],
};

Step 3: Adding a Remote shop App as a Git Submodule​

Since the shop app resides in a separate repository, we’ll add it as a Git submodule.

3.1 Generate shop remote app​

Similar to how we generated about app above, let's generate the shop remote app with Nx's Angular generator:

nx g @nx/angular:remote apps/shop --host=shell

This will generate a remote app shop in apps/shop/ directory and register it in the shell's module-federation.config.ts.

const config: ModuleFederationConfig = {
  name: 'shell',
  remotes: ['shop'],
};

3.2 Initialize shop Git submodule repository​

Let's initialize the remote app apps/shop as another Git repository.

cd apps/shop
git init
git remote add origin <GIT_REPO_URL_FOR_SHOP>

Navigate to the root of the monorepo and add it to the .gitmodules

git submodule add <GIT_REPO_URL_FOR_SHOP> apps/shop

# this track the changes for the latest commit of `shop` repo.
git add apps/shop

Step 4: Create an AWS S3 Bucket​

In order to host our MFE app, we need to enable the static site hosting in the S3 bucket.

Sample terraform script:

# ==================== S3 ====================
resource "aws_s3_bucket" "mfe_app" {
  bucket = "<your_bucket_name>"
}
resource "aws_s3_bucket_policy" "mfe_app_policy" {
  bucket = aws_s3_bucket.mfe_app.id
  policy = jsonencode(
    {
      Version = "2012-10-17"
      Statement = [
        {
          Sid       = "PublicReadGetObject"
          Action    = "s3:GetObject"
          Effect    = "Allow"
          Principal = "*"
          Resource  = "${aws_s3_bucket.mfe_app.arn}/*"
        },
      ]
    }
  )
}

# Enable static website hosting
resource "aws_s3_bucket_website_configuration" "mfe_app" {
  bucket = aws_s3_bucket.mfe_app.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "error.html"
  }
}
resource "aws_s3_bucket_public_access_block" "mfe_app" {
  bucket                  = aws_s3_bucket.mfe_app.id
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

Step 5: Building and Deploying to AWS S3​

Each app needs to be built and deployed to S3 buckets.

First, let's build the apps. This will generate the built arfifacts in dist/apps/.

nx build shell
nx build about
nx build shop

# alternatively, you can build all with:
nx run-many -t build

Then deploy each app to S3 whenever necessary.

aws s3 sync dist/apps/shell s3://my-mfe-bucket/shell --delete
aws s3 sync dist/apps/about s3://my-mfe-bucket/about --delete
aws s3 sync dist/apps/shop s3://my-mfe-bucket/shop --delete

Step 6: Setting Up CloudFront​

Now that we have deployed our MFE app to the S3. Technically we can already access it directly via the S3 public url, eg: http://<your-bucket-name>.s3-website-ap-southeast-1.amazonaws.com, but the redirection will not work properly when reloading the page.

Hence, we need to setup a CloudFront distribution and configure it to serve from the S3 bucket:

Terraform script:

resource "aws_cloudfront_origin_access_control" "oac" {
  name                              = "my-mfe-s3-access-control"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

# CloudFront distribution
resource "aws_cloudfront_distribution" "mfe_cloudfront" {
  # our MFE shell app is hosted in a S3 directory instead of root /, we need to tell CF where to look for index.html
  default_root_object = "shell/index.html"
  enabled             = true

  origin {
    # replace `<your_s3_bucket>` with your bucket name
    domain_name = "<your_s3_bucket>.s3-website-ap-southeast-1.amazonaws.com"
    origin_id   = "my_s3_origin"
    origin_access_control_id = aws_cloudfront_origin_access_control.oac.id
  }

  custom_error_response {
    error_caching_min_ttl = 10
    error_code            = 403
    response_code         = 200
    response_page_path    = "/shell/index.html"
  }
  custom_error_response {
    error_caching_min_ttl = 10
    error_code            = 404
    response_code         = 200
    response_page_path    = "/shell/index.html"
  }

  default_cache_behavior {
    allowed_methods = [
      "GET",
      "HEAD",
    ]
    cached_methods = [
      "GET",
      "HEAD",
    ]
    target_origin_id         = "my_s3_origin"
    viewer_protocol_policy   = "redirect-to-https"
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

This ensures requests are routed correctly to the MFE remotes.

Summary​

By following these steps, we: ✅ Created an Nx monorepo with an MFE setup ✅ Integrated a Git submodule for the shop remote app ✅ Built and deployed each MFE to AWS S3 ✅ Used AWS CloudFront to route requests dynamically

This architecture enables scalability, independent deployments, and improved maintainability for micro frontends.

Let me know if you have any questions or improvements! 🚀

Introduction

Recently, I had an initial interview with a new company that uses Angular and .NET as its tech stack. Frankly, these two frameworks are pretty unfamiliar to me. I used to work with Angular.js back when it was still v1, which was about 8 years ago. I remember it was renamed to just Angular starting from v2, and now it's already at v18.

What about .NET? Even worse, I have never used it in my entire life! In fact, I don't know C# at all. Though I've heard a lot about it and that it's similar to Java.

Long story short, regardless of whether I advance to the next interview, I decided to take this as an opportunity to learn some new skills. However, I don't want to spend too much time learning. So, I decided to start a speed run on learning .NET and Angular.

How I learn

How I usually learn a new framework or programming language is by building a sample project. Here are a few pros of this approach:

• Less boring - You get to see your half-baked product evolve while going through the tutorial.
• Learn based on the features you need - It takes time to learn everything, especially with a complex framework like .NET. It's better to learn as you go. For example, if you need user authentication or a database migration.
• Feels accomplished once the sample project is done and deployed for showcasing!

I have shared some of the notable points I learned from these frameworks here:

• Learning .NET
• Learning Angular

A Todo Project

And so, I decided to build a simple Todo task list. This Todo will contain the following features and acceptance criteria:

• A login page for user authentication
• Users can create, read, update, and delete a collection (a group of tasks)
• Users can create, read, update, and delete a task within a collection
• A main page with a two-pane layout: the left pane shows a list of collections, and the right pane shows the selected collection’s tasks
• Users must be authenticated to view the main page
• Basic UI styling (tailwind for the rescue!)
• Logout functionality

Deployment

Now that I have finished building the API and web app, I want to deploy them somewhere to showcase if needed. Since I already have AWS, I decided to deploy there.

I want it fast and simple, so here’s what I did:

• Hosted the Angular app on an S3 bucket as a static site
• Dockerized the .NET API and deployed it to an EC2 instance
• Created a Postgres instance in RDS

I used Terraform to ease the process of provisioning these resources. Here’s a sample script.

# VPC, subnets, internet gateway, route table and security groups provisioning
# ...

# ==================== RDS ====================
resource "aws_db_instance" "my_rds" {
  allocated_storage      = 20
  engine                 = "postgres"
  engine_version         = "16.4"
  instance_class         = "db.t3.micro"
  db_name                = "mydatabase"
  username               = "username"
  password               = "password"
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  db_subnet_group_name   = aws_db_subnet_group.my_db_subnet_group.name
  skip_final_snapshot    = true
  publicly_accessible    = false
}
resource "aws_db_subnet_group" "my_db_subnet_group" {
  name = "my-db-subnet-group"
  subnet_ids = [
    aws_subnet.private_subnet_a.id,
    aws_subnet.private_subnet_b.id
  ]
}

# ==================== EC2 ====================
resource "aws_instance" "dotnet_todo_instance" {
  ami                    = "ami-0a6b545f62129c495"
  instance_type          = "t2.micro"
  subnet_id              = aws_subnet.public_subnet_a.id
  vpc_security_group_ids = [aws_security_group.ec2_sg.id]
  tags = {
    Name = "dotnet-todo-ec2"
  }
}

# ==================== S3 ====================
resource "aws_s3_bucket" "dotnet_todo_web" {
  bucket = "dotnet-todo-web"
}
resource "aws_s3_bucket_policy" "dotnet_todo_web_policy" {
  bucket = aws_s3_bucket.dotnet_todo_web.id
  policy = jsonencode(
    {
      Version = "2012-10-17"
      Statement = [
        {
          Sid       = "PublicReadGetObject"
          Action    = "s3:GetObject"
          Effect    = "Allow"
          Principal = "*"
          Resource  = "${aws_s3_bucket.dotnet_todo_web.arn}/*"
        },
      ]
    }
  )
}

Result

Concluding Thoughts

Overall, it took me roughly one week to learn Angular, .NET, and complete the project. From a developer's perspective, the experience was quite smooth and easy. I found Angular's opinionated structure to be particularly beneficial. Its out-of-the-box common libraries saved me a significant amount of time that I would have otherwise spent searching for third-party solutions. This allowed me to focus more on building the actual features of my project rather than dealing with setup complexities.

When it comes to .NET, although I don’t particularly like C#’s Pascal-case naming conventions and its syntax formatting, I must admit that .NET is very easy to set up, develop, and build. I found the CLI and generators to be especially helpful tools that streamlined the development process. These tools provided a robust foundation, making it easier to manage and organize the codebase efficiently.

I built a simple todo for this project, but the learning experience has inspired me to explore more complex projects using Angular and .NET. I am definitely going to start building more with Angular and .NET in the future. The combination of these frameworks provides a powerful and efficient development environment that I am excited to continue exploring.