Micro-frontend

A micro-frontend is an independently built and deployed part of a web application, owned by one team and composed with other parts into a single product at runtime.

A micro-frontend architecture splits one web product into several smaller frontends. Each one covers a business area, such as checkout or reporting, and has its own codebase, build and release cycle. A thin host application loads them in the browser and makes them feel like one product: one URL space, one login, one look.

The idea borrows from microservices. The goal is team autonomy. A team can release its part without waiting for a shared release train and without retesting the whole application.

Example

An insurance portal has three teams: policies, claims and billing. Each team ships its own frontend to its own URL. The host owns the header, the navigation and the session. When the user opens /claims, the host fetches the claims frontend at runtime and renders it inside the layout. The claims team can deploy on a Tuesday afternoon and nobody else has to rebuild anything.

Common composition techniques include Module Federation, Native Federation, single-spa and web components. The micro-frontends page shows how these fit into a platform.

Common misunderstanding

Micro-frontends are often presented as a performance or code quality technique. They are an organizational tool, and they add real costs: shared dependency versions to manage, a design system to keep consistent, more pipelines and more ways to fail at runtime. A single team with one mid-size application usually gets better results from a well-structured monolith with lazy loading. The split pays off when several teams are blocked by each other's releases. The guide Rewrite, hybrid or micro-frontends covers when it is worth it.

Related terms

• Module Federation
• Host (shell) application
• Remote (micro-frontend remote)
• Conway's law