Conclusion
You've built a production microfrontends application from scratch. Let's review what you've learned and where to go next.
What You Built
The Acme Platform: a complete multi-zone application with:
acme-platform/
├── apps/
│ ├── marketing/ # Default app (/, /pricing, /about)
│ ├── docs/ # Child app (/docs/*)
│ ├── dashboard/ # Child app (/app/*, /settings/*)
│ └── legacy-proxy/ # Proxy for incremental migration
├── packages/
│ ├── ui/ # Header, Footer, SpeculationRules
│ └── utils/ # Auth helpers
├── microfrontends.json # Routing configuration
└── turbo.json # Task orchestration
This mirrors how Vercel structures vercel.com with 12 microfrontend projects.
Key Concepts Mastered
Section 1: Foundations
- When to use microfrontends - DX scaling and incremental migration
- Vertical vs horizontal - Split by route vs split by component
- Monorepo benefits - Shared packages, atomic commits, coordinated builds
Section 2: Vertical Microfrontends
- Configuration -
microfrontends.jsonandwithMicroFrontendswrapper - Routing order - Firewall → Microfrontends → Headers → Redirects → Middleware → Rewrites
- Path isolation - Each app only sees its own routes
- Local development - Proxy at localhost:3024
- Deployment - Fallback behavior (commit → branch → production)
Section 3: Production Patterns
- Performance - Speculation Rules for prefetching/prerendering
- Testing - Routing validation with
validateRouting - Observability - Debug headers and traces
- Security - Firewall rules cascade from default app
Section 4: Advanced Patterns
- Feature flags - Route users to different apps based on flags
- Migration - Strangler fig pattern for incremental adoption
- Remote components - When horizontal microfrontends make sense
Decision Framework
When evaluating microfrontends for a project:
┌─────────────────────────────────────────────────────────┐
│ Should you use microfrontends? │
├─────────────────────────────────────────────────────────┤
│ │
│ Build times >5 min? ───Yes───► Consider MFE │
│ │ │
│ No │
│ │ │
│ Multiple teams blocked ───Yes───► Consider MFE │
│ on each other? │
│ │ │
│ No │
│ │ │
│ Migrating from legacy? ───Yes───► Consider MFE │
│ │ │
│ No │
│ │ │
│ ► Try Turbopack first, stay monolithic │
│ │
└─────────────────────────────────────────────────────────┘
Quick Reference
| Scenario | Recommendation |
|---|---|
| Build times >5 min, multiple teams | Vertical microfrontends |
| Migrating from legacy stack | Microfrontends with feature flags |
| Single team, builds under 3 min | Stick with monolith + Turbopack |
| Same component across many sites | Consider horizontal (when stable) |
| Tightly coupled UX, frequent cross-navigation | Probably not microfrontends |
Common Pitfalls to Avoid
| Pitfall | Prevention |
|---|---|
| Central middleware assumptions | Remember: each app's middleware is isolated |
| Asset collisions | Always use withMicroFrontends wrapper |
| Redirect confusion | Redirects only run in the app that receives the request |
| Over-engineering | Start simple, add complexity when needed |
| Premature adoption | Microfrontends have overhead. Earn that cost. |
Your Next Steps
- Clone a template - Start with a working example
- Audit your application - Identify natural boundaries
- Start small - Extract one section before going all-in
- Deploy to preview - Test routing before production
- Monitor and iterate - Use observability to catch issues
Course Complete
You now have the knowledge to:
- Evaluate whether microfrontends solve your problems
- Build and deploy vertical microfrontends on Vercel
- Optimize performance with Speculation Rules
- Test and debug routing configurations
- Implement gradual rollouts with feature flags
- Plan migrations from legacy applications
Thank you for taking this course. Now go build something great.
Resources
Official Documentation
Templates
Code
Further Reading
Was this helpful?