Introduction
Micro Frontend extends the idea of Microservices to frontend: dividing the web application into small parts, each part is owned, developed and deployed independently by a team. This article explains why Micro Frontend is needed and when it should (or should not) be used.
1. What is Micro Frontend?
1.1 Definition
"An architectural style where independently deliverable frontend applications are composed into a greater whole." — Cam Jackson, Martin Fowler Blog
Monolith Frontend: Micro Frontend:
┌─────────────────────────┐ ┌─────────────────────────┐
│ Single SPA │ │ Shell Application │
│ ┌─────────────────────┐ │ │ ┌──────┐ ┌──────┐ ┌──┐ │
│ │ Header │ │ │ │Shared│ │Shared│ │ │ │
│ ├──────┬──────┬───────┤ │ │ │Header│ │Footer│ │ │ │
│ │Produ-│ Cart │ Order │ │ │ └──────┘ └──────┘ │ │ │
│ │cts │ │ │ │ │ ┌──────┐ ┌──────┐ │ │ │
│ │ │ │ │ │ ──► │ │Produc│ │ Cart │ │Or│ │
│ │ │ │ │ │ │ │t MFE │ │ MFE │ │de│ │
│ │ │ │ │ │ │ │Team A│ │Team B│ │rC│ │
│ ├──────┴──────┴───────┤ │ │ └──────┘ └──────┘ └──┘ │
│ │ Footer │ │ │ Deploy Deploy De │
│ └─────────────────────┘ │ │ riêng riêng ploy │
└─────────────────────────┘ └─────────────────────────┘
1 team, 1 repo, 1 deploy N teams, N repos, N deploys
1.2 Micro Frontend vs Component Library
| Component Library | Micro Frontend | |
|---|---|---|
| Deploy | Same app host | Independent |
| Team ownership | Shared | Dedicated team |
| Tech stack | Similar | Can differ |
| Runtime loading | Build-time | Runtime |
| Data/state | Shared in memory | Isolated |
2. Why do we need Micro Frontend?
2.1 Practical problem
You have 5 teams working on 1 monolith SPA:
- Continuous PR conflicts (500+ components, shared state)
- Long Merge Queue → deploy once/week
- A team wants to upgrade React 18, but needs the entire app to migrate
- Bug on product page → rollback the whole app (cart, order are also affected)
→ Micro Frontend solves the organizational scaling problem.
2.2 Main benefits
| Benefits | Description |
|---|---|
| Independent Deployment | Ship product page without affecting cart |
| Team Autonomy | Each team owns end-to-end (UI → BFF → Service) |
| Tech Flexibility | Team A uses React, Team B uses Vue (if necessary) |
| Incremental Upgrade | Upgrade each MFE, no need for big bang |
| Fault Isolation | Bug in MFE A does not crash MFE B |
| Faster Development | Smaller codebase = faster build, test, deploy |
3. Trade-offs & Challenges
3.1 When Micro Frontend is NOT suitable
- Small team (< 5 devs): overhead is too large compared to the benefits
- Simple app: landing page, blog, simple dashboard
- Tight UX coupling: the application needs seamless UX between parts
- Performance-critical: add runtime overhead (loading, bootstrapping)
3.2 Complexity costs
Micro Frontend thêm complexity:
├── Infrastructure: CI/CD cho nhiều apps
├── Shared dependencies: versioning hell
├── UX Consistency: design system bắt buộc
├── Communication: cross-MFE events
├── Performance: bundle size, load time
├── Testing: integration testing across MFEs
└── Developer Experience: local dev setup phức tạp
4. Decision Framework
Bạn nên dùng Micro Frontend khi:
✅ Team size: 15+ frontend developers
✅ Multiple teams working on same app
✅ Deploy frequency: team muốn deploy độc lập
✅ App complexity: 10+ distinct features/pages
✅ Tech migration: cần incremental migration
❌ Skip Micro Frontend khi:
❌ Team < 5 developers
❌ Single team, shared ownership
❌ App chưa đủ phức tạp
❌ Performance là yếu tố quyết định
❌ Team chưa có experience với Microservices
Summary
Micro Frontend is not a silver bullet — it solves the organizational scaling problem. If you don't have that problem, don't create unnecessary complexity.
Next article: Lesson 11: Micro Frontend Integration Strategies — Build-time vs Run-time