Vijay Singh
Back to Blogs
Micro-Frontends
Nov 08, 2024
11 min read

Micro-Frontends: A Practical Guide

Breaking down monolithic frontends using Module Federation. When to use it and when to avoid it.

Micro-Frontends: A Practical Guide

As frontend codebases scale to millions of lines of code and hundreds of developers, the "Monolith" becomes a bottleneck. Compile times slow to a crawl, and one bad deploy breaks the whole site.

The Concept

Micro-frontends apply Microservices architecture to the frontend. You split your application into smaller, independent apps (e.g., 'Cart App', 'Product App', 'Profile App') that are stitched together at runtime to look like a single cohesive site.

Webpack Module Federation

Before Webpack 5, this was hard (using IFrames or loaded scripts). Module Federation changed the game. It allows a JavaScript application to dynamically load code from another build at runtime.

App A can import Header from App B just like a normal NPM package, but the code for Header actually lives on App B's server.

Benefits

  • Independent Deployments: Team Checkout can deploy a fix without waiting for Team Home Page.
  • Technology Agnostic: Theoretically, one part of the page could be React and another Vue (though not recommended for performance).
  • Incremental Upgrades: You can rewrite one section of a legacy structure at a time.

The Price of Complexity

It's not a silver bullet. You face challenges with:

  • Shared Dependencies: Loading React twice is bad. You need to configure sharing properly.
  • CSS Isolation: Styles for one app leaking into another.
  • Consistent UX: Keeping the Design System synced across 5 different repos is hard organizational work.

Verdict: Don't use Micro-frontends unless your organization structure demands it. For most, a Monorepo is a better first step.

Micro-FrontendsWebpackArchitecture
Vijay Kumar Singh | Frontend Engineer