The micro-frontend host: what it is responsible for and what it must not do

The host is the first application the browser loads and the one piece every team depends on. Keeping it small is the most important design decision in a micro-frontend platform.

The host in one sentence

The host, also called the shell, owns what is common to the whole product and loads everything else on demand.

It is loaded on every visit, and every remote runs inside it. A mistake in the host affects all teams at once. That is the reason for both lists below.

What the host is responsible for

Top-level routing

The host maps URL prefixes to remotes. /billing/... belongs to the billing remote, /catalog/... to catalog. The host knows the prefix and nothing about the routes inside it. Details are in Routing across micro-frontends.

Login and session

The host starts the login flow, keeps the session and exposes the current user to the remotes. Remotes consume the session and never create one. See Shared authentication.

Layout

The header, the main navigation, the footer and the content area where the active remote renders. Product-wide controls live here too: the language selector, the theme, global notifications.

Loading remotes

The host knows where each remote lives, normally through a manifest fetched at startup. It loads a remote when its route is first visited and shows a loading state in the meantime.

Fallback

Remotes sometimes fail to load. The host decides what the user sees in that case: an error panel in the content area, a retry action, and navigation that keeps working so the user can go elsewhere.

In Angular, loading a remote is a promise inside a lazy route, so a fallback can be a catch that returns local routes:

{
  path: 'billing',
  loadChildren: () =>
    loadRemoteModule('billing', './routes')
      .then(m => m.BILLING_ROUTES)
      .catch(() => REMOTE_UNAVAILABLE_ROUTES)
}

Cross-cutting plumbing

The global error handler, telemetry setup, feature flag bootstrap and locale. These are initialized once and offered to remotes through shared packages.

What the host must not do

• Contain business logic. No domain screens and no API calls about invoices or orders. A dashboard that mixes data from several areas is itself a remote with an owner.
• Know the internals of a remote. No imports of remote types, no knowledge of internal routes, no special cases per remote in the code.
• Act as the shared library. Utilities belong in versioned packages. When remotes import helpers from the host, every remote depends on the host's release cycle.
• Hold feature state. Cart contents, filters and form drafts belong to the remote that owns them, or to the backend.
• Require a release to add or update a remote. Remote locations and menu entries come from configuration read at runtime.
• Grow heavy. Every kilobyte in the host is paid on every page of the product.

The contract the host offers

Remotes need a few things from the host. Write them down and version them like an API.

Anything outside this contract is private to the host. Remotes that reach into the host's DOM or internal services will break on the next host release, and the host team is right to let them.

Who owns the host

A small platform team. The host changes less often than any remote, and its changes get stricter review, because the blast radius is the whole product. Its pipeline should include a smoke test that loads every remote before a release is promoted.

Feature teams contribute to the host through the platform team, the way they would contribute to any shared library. Team structure is discussed in Team ownership and Conway's law.

Checklist

1. Can a new remote be added without rebuilding the host?
2. Does the product stay usable when one remote fails to load?
3. Is there any business API call in the host? If so, move it.
4. Is the contract between host and remotes written down and versioned?
5. Does every host release run a smoke test against all remotes?
6. Is the host's bundle size tracked over time?

More in this section

• Routing across micro-frontends: route ownership, deep links and the navigation contract
• Sharing login and session across micro-frontends
• How micro-frontends communicate, and what to avoid
• Shared dependencies and versions in micro-frontends