Micro-frontends
Splitting a frontend into coarse-grained, self-contained, independently deployable units, each owned by one team. Held here from micro-frontends-migration.
What it is not
A component loaded at runtime. The distinction is the pattern’s whole content, and Mezzalira draws it on what is being optimized:
| Components | Micro-frontends | |
|---|---|---|
| Grain | fine | coarse |
| Who knows the behaviour | the container configures it | the unit itself, “aware of how the things are working” |
| Optimized for | reusability, UI consistency | independence, fewer cross-team dependencies |
| Cost | coupling — “when you optimize for reusability, you create coupling” | duplication, distributed-system overhead |
“It cannot be a component loaded at runtime, because what we want instead is optimized for
independence.” That sentence is also this spoke’s boundary with ../ui-frameworks-wiki.
The decisions it forces
- Vertical or horizontal split. Vertical groups whole views by domain; horizontal puts several micro-frontends inside one view. Horizontal splits are what make cross-unit communication a problem.
- app-shell or UI composer. Something has to own configuration, authorization, composition and routing.
- Where rendering happens — server or client.
- Where routing happens — edge, API gateway, or client. Global routing (first-level URLs) means a hard navigation into another unit; local routing stays inside one.
- How units talk. Cookies or local storage for persistent data, query strings for ephemeral data, event emitters for horizontal splits. Not global state — one team spent four months shipping nothing refactoring theirs.
Choosing the units
By code volatility, starting coarse and splitting later rather than earlier. The worked example is DAZN, cut into five: landing, onboarding, catalog-plus-player, account, help.
What it costs, stated by its advocate
It is “not a silver bullet” and needs a distributed-systems mindset. The named failure states: micro-frontends anarchy (mixed frameworks and versions as a permanent condition rather than a migration phase), premature abstraction of shared components, and everything loaded at runtime with no plan.
The reason to do it is organizational
Team autonomy, organizational scalability, agility, fast flow — micro-frontends-migration puts these before any technique, which means the pattern is a socio-technical choice: architecture, organization and engineering culture move together. See application-architecture.
The number, and what it is actually about
One team went from 3 deployments a month to 25 a day per team after migrating. The stated cause is the “safe net” of edge-compute canary and configuration rollback, not modularity itself — which makes it evidence about reversibility, and a caution against reading it as the payoff of splitting a frontend.
Related
application-architecture · app-shell · micro-frontends-migration · feature-first-structure · luca-mezzalira · synthesis