When Your Frontend Becomes a Monolith
It starts innocently. A single Next.js app with a few pages. Then a few dozen. Then your bundle is 8MB, builds take 15 minutes, and three teams are stepping on each other's code.
Sound familiar?
The Monolith Frontend Problem
- Build times grow linearly with codebase size.
- Deployment risk — a CSS change in the checkout page breaks the dashboard.
- Team coupling — everyone works in the same repo, same CI/CD pipeline.
The Micro-Frontend Solution
Micro-frontends apply microservice principles to the frontend. Each team owns a vertical slice — from the UI layer down to its own API.
Our Approach at BWS
┌──────────────────────────────────────┐
│ App Shell (Host) │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ Header │ │ Main Content │ │
│ │ (shared)│ │ ┌────┐ ┌────┐ │ │
│ │ │ │ │ MF │ │ MF │ │ │
│ │ │ │ │ A │ │ B │ │ │
│ └──────────┘ │ └────┘ └────┘ │ │
│ └──────────────────┘ │
│ ┌──────────────────────────────────┐│
│ │ Footer (shared) ││
│ └──────────────────────────────────┘│
└──────────────────────────────────────┘
Key Decisions
- Module Federation — Webpack 5's Module Federation for runtime composition.
- Shared Design System — A single npm package for UI primitives (buttons, cards, inputs).
- Independent Deployments — Each micro-frontend deploys to its own CDN path.
- Event Bus — Cross-module communication via custom events, not direct imports.
Trade-offs
Micro-frontends aren't free. They add complexity in:
- Routing — Who owns which URL?
- State sharing — Global auth state must be available everywhere.
- Consistency — Version drift in the shared design system.
But for organizations with 3+ teams working on distinct product areas, the autonomy gains far outweigh the costs.
