Mastering Build-Time Integration: Simplifying Microfrontend Composition with Webpack Module Federation

Introduction

Microfrontends are revolutionizing how we build and scale frontend applications by breaking them into independently developed and deployed pieces. One of the earliest and simplest ways to compose Microfrontends is through Build-Time Integration (Static Composition).

This approach assembles all Microfrontend parts during the build phase, resulting in a single, fully integrated application that is deployed as a whole.

In this blog, we’ll dive into:
✅ What is Build-Time Integration?
✅ How it works in Microfrontends
✅ Pros and Cons
✅ Common Use Cases
✅ Example Implementation using Webpack Module Federation

What is Build-Time Integration?

Build-Time Integration (also known as Static Composition) means that all Microfrontends are combined into a single, fully integrated build during the compilation phase. Unlike dynamic or runtime integration, where Microfrontends are loaded on-demand, this method bundles everything into one deployable artifact.

🔹 Think of it like this: Imagine assembling LEGO blocks into a fixed structure before delivering it. The structure can’t be changed afterward without rebuilding it entirely.

Key Characteristics:

• Microfrontends are pre-assembled during CI/CD.
• The final build contains all the necessary code and dependencies.
• Deployment happens as a single unit.
• No dynamic loading or independent deployments.

How Build-Time Integration Works in Microfrontends

1. Microfrontends as Dependencies
   Each Microfrontend is treated as a package dependency (e.g., using npm or yarn). The host application imports these dependencies and integrates them before the build process.
2. Webpack Module Federation for Sharing Code
   Module Federation in Webpack allows separate applications to share and consume modules at runtime. However, in a build-time setup, dependencies are fixed at the time of compilation.
3. Deployment as a Single Bundle
   Since everything is integrated at build time, the final output is a monolithic frontend that gets deployed as a single entity.

📌 Example Flow:

1️⃣ Each Microfrontend is developed separately.
2️⃣ They are published as npm packages or linked via Git submodules.
3️⃣ The host application imports these Microfrontends as dependencies.
4️⃣ The build process bundles them into a single output.

Example Implementation Using Webpack Module Federation

In this section, we’ll walk through the code setup to achieve Build-Time Integration using Webpack and Module Federation.

1️⃣ Microfrontend Header (microfrontend-header) Setup

The Microfrontend Header is the remote Microfrontend that exposes a Header component for the Host Application (app-shell) to consume.

Install Dependencies:

Create webpack.config.js

Create src/Header.js

Create src/index.js

Create public/index.html

Start the Application

2️⃣ Host Application (app-shell) Setup

The Host Application (app-shell) will dynamically load the Header component exposed by the Microfrontend Header app.

Install Dependencies:

Create webpack.config.js

Create src/index.js

Create public/index.html

Start the Application

Pros and Cons of Build-Time Integration

✅ Pros:

• Simpler Development & Integration — No need to worry about runtime module loading.
• Better Performance — No additional runtime overhead for fetching remote modules.
• Easier Dependency Management — All dependencies are resolved before deployment.
• Familiar Workflow — Works well with traditional frontend architectures.

❌ Cons:

• Tightly Coupled Deployments — Every Microfrontend must be built and deployed together.
• No Independent Versioning — Any update requires rebuilding the entire application.
• Lack of Flexibility — No ability to switch Microfrontends dynamically at runtime.

Use Cases for Build-Time Integration

• Best for Small to Medium-Sized Applications
• When Microfrontends Are Developed by a Single Team
• When Versioning is Not a Concern
• For Applications with Limited Microfrontend Updates

❌ Not ideal if: You need independent deployments or frequent updates. In such cases, Runtime Integration is a better approach.

Conclusion

📌 When to Use Build-Time Integration?
✅ If you want a simpler, monolithic-like deployment
✅ If all Microfrontends have a shared release cycle
✅ If you want better performance without runtime overhead

📌 When NOT to Use It?
❌ If Microfrontends need independent deployment
❌ If you require version mismatches handling
❌ If you expect frequent UI updates

In future blog series, you will explore more patterns for architecting Microfrontends! 😊