What is a micro frontend (MFE)?

MFE stands for micro frontend (also written micro-frontend or microfrontend). A micro frontend is an independently built, tested and deployed piece of a web application — a checkout flow, a dashboard, a search widget — that is combined with other micro frontends at runtime to form a single product. It is the same idea as microservices, applied to the browser: instead of one frontend codebase released as one unit, you have several small ones released on their own schedules.

The term is usually written MFE in tooling and job descriptions. If you arrived here looking for a different MFE, this page is about frontend architecture.

How a micro frontend application fits together

There is a host application — often called the shell or the container. It owns the page frame, routing and authentication, and it decides which micro frontends to place where.

Each micro frontend is built separately into its own bundle and published somewhere the browser can reach it. At runtime the host fetches those bundles and mounts them into the page.

The loading itself is usually done with Module Federation, a bundler feature that lets one application consume code from another at runtime and share common libraries between them. Web components and import maps are the other common approaches.

What none of these mechanisms answer is which version of each micro frontend a given environment should load. Answer that in the host's source code and you are back to rebuilding the host for every release — which is the reason micro frontend orchestrators exist.

What you gain

  • Independent deployment

    A team ships its own part of the product when it is ready, without waiting for a shared release.

  • Team autonomy

    Each micro frontend has an owner, a repository and a pipeline, so responsibility is unambiguous.

  • Framework freedom

    A new area can be built in a different framework, and a legacy area can be replaced piece by piece.

  • Smaller blast radius

    A broken release affects one part of the interface rather than the whole application.

What it costs

  • Runtime integration

    Something has to load the right pieces, in the right versions, at the right time. This is the problem an orchestrator solves.

  • Duplicated dependencies

    Without shared dependencies, every micro frontend ships its own copy of React and users download it several times.

  • Version drift

    With no registry, nobody can say which version of which micro frontend is live in which environment.

  • Operational overhead

    More pipelines, more artifacts and more places to look when something breaks.

When micro frontends are worth it

Micro frontends solve an organisational problem before a technical one. They pay off when several teams contribute to one product and keep blocking each other: a shared release train, a merge queue nobody enjoys, a build that grows slower every quarter.

For a single team on a single application, they mostly add work. One codebase with good module boundaries is easier to run than four deployables that have to agree on a runtime.

The honest rule of thumb: adopt micro frontends when the cost of coordinating teams exceeds the cost of coordinating deployments.

Where MFE Orchestrator comes in

MFE Orchestrator is the control plane for the part the architecture leaves to you. It stores each build, keeps a version history per environment, serves the runtime configuration your host reads on startup, and handles canary releases and rollback. You get independent deployment for real — releasing a micro frontend never rebuilds the host.