In a microfrontend architecture using Webpack Module Federation, what is the difference between a 'host' application and a 'remote' application, and how do they connect at runtime?

## The vocabulary Module Federation is a Webpack 5 (and now Vite-ecosystem) capability that lets multiple, independently built and independently deployed JavaScript bundles share code with each other at runtime, through the browser, rather than at build time through a shared repository or npm package. The core vocabulary is 'host' and 'remote.' - A **host** is the application the user's browser loads first — typically a shell or container app that owns the page's routing, top-level layout, and authentication. - A **remote** is a separately built and separately deployed application that exposes some of its internal modules (a component, a page, a utility function) for other applications to consume. Critically, any single application can play both roles at once: a 'team B' app can be a remote to the shell while itself acting as a host to a smaller widget owned by 'team C.' This is what makes Module Federation a true architecture for horizontally scaling frontend ownership across teams, rather than just a code-splitting trick. ## How the connection is made Mechanically, the connection happens through a small, auto-generated file called the container, conventionally named `remoteEntry.js`. When a remote app is built with the ModuleFederationPlugin's `exposes` option, Webpack emits this container alongside the remote's normal bundles. The container is a tiny piece of JavaScript that, once loaded into any page's global scope, registers itself under the remote's configured name and exposes two functions the specification calls the container protocol: - `init(shareScope)`, which lets the container register itself into a shared dependency scope so it can, for example, reuse the host's already-loaded copy of React instead of shipping its own. - `get(moduleName)`, an async function that returns the actual exposed module on demand. On the host side, a `remotes` entry in its own `ModuleFederationPlugin` config tells Webpack 'there is a remote called catalog, reachable at this URL for its remoteEntry.js.' When host code executes `import('catalog/ProductList')`, Webpack's runtime — not the bundler at build time — fetches remoteEntry.js over the network if it hasn't been fetched already, calls init then get, and resolves the import with the live module. Nothing about the remote's internal code needs to exist in the host's repository or build pipeline at all; the two apps can use completely different CI/CD pipelines, deploy on independent schedules, and even be owned by different teams with no coordinated release train. ## Why it exists The reason this exists is organizational as much as technical. Before Module Federation, teams splitting a large frontend into independently deployable pieces had few good options: | Approach | What it buys | Where it falls short | |---|---|---| | iframes | heavy isolation | poor UX — no shared routing, styling, or state, and painful cross-frame communication | | build-time monorepo composition | fast and safe | forces a single release train and a single Webpack config, defeating the purpose of team autonomy | | hand-rolled script-tag loading of UMD bundles | works | reinvents dependency sharing and versioning badly | Module Federation gives near-native integration — remote components render as first-class components inside the host's tree, sharing the same DOM, router, and even framework runtime — while still letting each remote be built, versioned, and deployed completely independently, often on its own CDN path, with its own on-call team. ## The trade-off The trade-off is that this convenience is paid for with **runtime coupling** and a wider failure surface than either extreme. - Because the host fetches `remoteEntry.js` live in the user's browser, the host now has an implicit runtime dependency on the remote's availability, its CDN, its CORS configuration, and its compatibility with whatever shared library versions the host has already loaded. A remote that renders fine in isolation can throw at runtime in the host if it assumes a newer framework version than the host's singleton copy provides. - Debugging is also harder: stack traces cross the boundary between two bundles compiled independently, source maps must be shipped and correctly resolved for each remote, and a bug might only reproduce in the specific host+remote+shared-version combination running in production, not in either app's own dev environment. ## Where it shows up A realistic scenario: an e-commerce shell app owned by a platform team hosts a checkout remote owned by a payments team and a catalog remote owned by a merchandising team. Each team ships to production multiple times a day without touching the shell's repository or waiting on the platform team's release calendar — the shell only needs the remote's stable exposed URL and a compatible shared-dependency contract, and every deploy of checkout is instantly live to the user the next time the shell resolves that remote entry.