Micro-frontend
A micro-frontend architecture decomposes a single web application into multiple independently developed and deployed frontend modules — each owned by a different team and integrated at runtime (via Module Federation, iframes, or web components) or build time (via package composition). The pattern extends microservices thinking to the frontend.
Micro-frontends address the frontend monolith problem at scale: a single SPA owned by 8 teams becomes a release coordination nightmare. The architecture lets teams ship independently — Team A's micro-frontend updates without re-deploying Team B's. The trade-offs are real: shared dependencies (React versions, design tokens, auth state) require explicit coordination; bundle size grows because shared code is harder to dedupe; runtime composition (Module Federation) carries genuine integration risk. The pragmatic threshold: fewer than 4 teams owning the frontend rarely justify micro-frontends; more than 10 teams almost always do.
Related terms
- Backend for frontend (BFF)
A backend-for-frontend is a dedicated server-side layer per client type (web, iOS, Android, partner API) that adapts the underlying services to that client's specific needs — aggregating multiple service calls, reshaping payloads, and exposing only the endpoints that client requires.
- Monorepo
A monorepo is a version-control repository that contains many distinct projects (services, libraries, tools) with shared tooling and atomic cross-project changes.
- Island architecture
Island architecture is the frontend pattern where most of a page is static server-rendered HTML with no client JavaScript, and only the interactive components (the 'islands') hydrate independently.