Micro-Frontends

Micro-frontends extend the microservices idea to the frontend: instead of one monolithic application, you build a shell that loads and orchestrates multiple independent "mini-apps," each owned and deployed by different teams. The approach has clear benefits and real costs—understanding both is essential before adoption.

What Are Micro-Frontends?

A micro-frontend architecture splits a frontend into semi-independent applications. Each micro-frontend typically maps to a business domain or team (e.g., checkout, product catalog, user profile). Teams can develop, test, and deploy their slice independently, using different frameworks or technologies if needed.

The host application (shell) is responsible for loading micro-frontends, routing between them, and providing shared concerns like authentication, theming, and navigation. Micro-frontends communicate via events, shared state, or URL parameters rather than direct imports.

When to Use Micro-Frontends

Micro-frontends make sense when:

• Multiple teams work on distinct areas of the same product and need independence in release cycles and tech choices.
• Legacy migration is underway—you can incrementally replace parts of an old app without a big-bang rewrite.
• Scale and autonomy matter—teams can own their full vertical (UI + API) and ship without coordinating with everyone.

They are less suitable when: