Module 11: Creating the Remote Micro Frontend Applications in Angular

Creating the Remote Micro Frontend Applications in Angular

Lesson Overview

In this lesson, we will create the two Micro Frontend applications that will integrate into our main system.

By the end of this lesson, you will have:

• One Host application (vendas)
• Two Remote applications (produtos and grafico)

Each micro frontend will be:

• a fully independent Angular application
• developed and deployed separately
• later integrated dynamically using Module Federation

Understanding the Architecture

Our system will consist of three Angular applications:

• Vendas → Host application (application shell)
• Produtos → Product listing micro frontend
• Grafico → Sales chart / admin micro frontend

This mirrors real-world scenarios where:

• one team handles product-related features
• another team handles analytics or admin features
• a central application orchestrates everything

Step 1: Preparing the Terminal

Make sure you are in the root folder that contains all projects:

micro-frontend/

Clear the terminal:

clear

This keeps the setup process clean and readable.

Step 2: Creating the First Micro Frontend (Produtos)

We will now create the Products micro frontend.

Run the following command:

npx @angular/cli@20 new produtos

Explanation:

• This creates a standalone Angular 20 application
• produtos will later expose components to the Host
• It represents the product listing section of our system

Step 3: Project Setup Options

When prompted by Angular CLI, use these options:

• Stylesheet format → CSS
• Server-Side Rendering (SSR) → No
• Zone.js → No

We keep all micro frontends consistent with the Host:

• same Angular version
• same configuration
• fewer integration issues later

Angular will now generate the produtos application.

Step 4: Creating the Second Micro Frontend (Grafico)

While the first project is being created (or after it finishes), create the second micro frontend.

Run:

npx @angular/cli@20 new grafico

This application represents:

• sales reports
• charts
• administrative or analytical features

In a real company:

• this could belong to a different team
• have a separate roadmap
• be deployed independently

Use the same configuration options as before.

Step 5: Verifying the Project Structure

Once both projects are created, open the workspace in VS Code:

code .

You should now see three Angular projects:

micro-frontend/
├── vendas     (Host application)
├── produtos   (Micro Frontend – Products)
└── grafico    (Micro Frontend – Sales Chart)

Each folder is:

• a complete Angular application
• fully independent
• capable of running on its own

This structure is intentional and architectural.

Step 6: Independence of Micro Frontends

At this stage:

• produtos can run without vendas
• grafico can run without vendas
• each app has its own package.json
• each app has its own build process

This independence is not optional.

It is a core requirement of Micro Frontend architecture.

What We Achieved in This Lesson

So far, we have:

• Created two Angular Micro Frontend applications
• Ensured all projects use the same Angular version
• Organized the workspace for multi-project architecture
• Prepared the system for Module Federation integration

At this point, nothing is connected yet — and that's correct.

Good architecture is built in layers.

What's Next

In the next lesson, we will:

• Configure Module Federation
• Expose modules from produtos and grafico
• Consume them dynamically inside the vendas Host application
• Understand how routing works across micro frontends

This is where the architecture becomes visible.

Schoolabe Insight

Micro Frontends are not about splitting code randomly.

They are about:

• splitting responsibility
• splitting ownership
• splitting deployment risk

The fact that these applications already work independently

means the architecture is heading in the right direction.