Micro frontends apply microservices principles to frontend development—breaking monolithic UIs into independently deployable pieces owned by different teams. Here's when this makes sense and how to implement it.
What Are Micro Frontends?#
Monolithic Frontend#
Single codebase, single build, single deployment
├── Header (Team A modified)
├── Product Catalog (Team B owns)
├── Shopping Cart (Team C owns)
└── Checkout (Team B modified)
Problems:
- Coordination overhead
- Deployment coupling
- Scaling teams is hard
- Technology lock-in
Micro Frontend Architecture#
Independent apps, independent builds, independent deployments
├── Shell App (Platform Team)
│ ├── Header MFE (Team A)
│ ├── Catalog MFE (Team B)
│ ├── Cart MFE (Team C)
│ └── Checkout MFE (Team D)
Benefits:
- Independent deployments
- Team autonomy
- Technology diversity
- Incremental upgrades
When to Use Micro Frontends#
Good Fit#
✓ Large organization (5+ frontend teams)
✓ Different teams own different features
✓ Need independent deployment cycles
✓ Diverse technology requirements
✓ Gradual migration of legacy systems
Poor Fit#
✗ Small teams (< 5 developers)
✗ Single-page applications with tight coupling
✗ No clear domain boundaries
✗ Need maximum performance
✗ Simple content sites
Integration Patterns#
Build-Time Integration#
Pros: Simple, type-safe, optimized bundle Cons: Requires shell rebuild for updates, version coupling
Runtime Integration (Module Federation)#
Pros: True independence, runtime updates, partial failures Cons: Runtime overhead, complexity, shared dependency coordination
Web Components#
Pros: Framework agnostic, native browser support Cons: Limited styling options, SSR challenges
iframes#
Pros: Complete isolation Cons: Poor UX, SEO issues, communication overhead
Module Federation Deep Dive#
Exposing Components#
Shared State#
Communication Between MFEs#
Routing#
Shell-Owned Routing#
MFE-Owned Routing#
Styling Strategies#
CSS Modules / Scoped Styles#
CSS-in-JS with Namespacing#
Shadow DOM#
Testing Micro Frontends#
Unit Testing (Same as Before)#
Integration Testing#
Contract Testing#
Performance Considerations#
Bundle Size#
Loading Strategy#
Deployment#
Independent Deployments#
Version Management#
Conclusion#
Micro frontends solve organizational scaling problems—enabling independent teams to work on independent codebases with independent deployments. But they add complexity that isn't worth it for smaller teams.
Evaluate honestly: if your frontend team is under 10 people and you don't have clear domain boundaries, a well-structured monolith is probably better. But if you're at the scale where team coordination is the bottleneck, micro frontends can unlock significant velocity.
Start with module federation, establish clear contracts between MFEs, and invest in shared tooling. The architecture complexity is justified by team independence.