Official source
Micro Frontends in Action
A book about decomposing the frontend into feature-driven modules and practical migration strategies from monolith.
Micro Frontends in Action
Authors: Michael Geers
Publisher: Manning Publications, 2020
Length: 296 pages
Michael Geers on decomposing the frontend into independent vertical slices: composition, team integration and migration from a monolithic SPA.
OriginalThe main idea of the book
Micro frontend - this is not about “many small React applications”, but about independent product verticals with clear boundaries of responsibility. Teams are entitled to autonomous releases, but are required to adhere to the overall platform contract: navigation, identity, design system and observability.
Composition models
Server-side composition
Shell assembles the page on the server and returns a single HTML. Strengths: SEO, predictable first paint, centralized routing control.
Client-side runtime composition
Modules are downloaded and installed in the browser. Pros: independent team releases, fast experimental deliveries.
Build-time composition
Assembly of all domain modules into a single artifact. It’s easier to start, but the independence of the teams during releases is lower.
What should be the common layer
Platform contract
- Routing rules and deep-link compatibility.
- Auth/session boundary and token propagation.
- Unified observability (logs, traces, frontend metrics).
- Design tokens and basic UI primitives.
Team model
- Ownership by business domains, not by UI layers.
- Autonomous CI/CD for each vertical slice.
- Versioning shared contracts + deprecation policy.
- Regular architectural reviews at module boundaries.
Practical migration roadmap
- Select bounded contexts in the frontend: catalog, cart, checkout, profile, etc.
- Introduce a shell container and unified contracts: routing, auth, observability, design tokens.
- Transfer zones gradually (strangler pattern), without rewriting the entire SPA in one release.
- Stabilize integration through contract tests and versioning of shared APIs.
- Strengthen governance: ownership, SLA for shared layer, process of breaking changes.
Antipatterns
- Split the frontend into UI libraries instead of business domains.
- Create dozens of shared packages and lose the autonomy of teams.
- Don't agree on uniform auth/routing/telemetry contracts.
- Trying to migrate the entire legacy frontend with one big-bang release.
- Ignore the performance budget and the total weight of client modules.