In a microfrontends architecture, what is the core difference between integrating a microfrontend at build time versus at runtime?

## What build-time integration means Build-time integration means a microfrontend's source code, or a compiled form of it, becomes part of the host application's own build pipeline and ends up in a single deployable artifact. The two common mechanisms are: 1. **Publishing the microfrontend as a versioned npm package** that the host lists as a dependency and installs. 2. **Placing the microfrontend directly inside a monorepo** that the host imports via a workspace path. Either way, a bundler such as **Webpack**, **esbuild**, or **Vite** traces the import graph at compile time and emits one JavaScript bundle (or a small, host-controlled set of chunks). The browser never independently requests the microfrontend's code; it is already inlined into whatever the host shipped. ## What runtime integration means Runtime integration keeps each microfrontend as its own independently built and independently deployed set of files, discovered by the host through a URL rather than an import statement resolved at compile time. - **Webpack Module Federation** (and its Rspack/Vite equivalents) is the most common mechanism today: the host declares a `remotes` map pointing at a manifest file the remote publishes, and at some point during page load — often lazily, when a route needs it — the host fetches that manifest, negotiates shared dependencies, and dynamically imports the remote's real code. - **Simpler variants** use native browser import maps or plain dynamic `<script>` tags pointing at a versioned URL. In every case, the defining trait is that the browser makes a live network request for code the host's own build never contained. ## The trade-off The reason this split exists is a genuine trade-off between two things teams want simultaneously and can't fully have at once: compile-time safety and deploy independence. - **Build-time integration** gives you a single artifact to test, version, and reason about — TypeScript can check that a microfrontend's exported component matches what the host expects, and the bundler can dedupe shared libraries precisely. The cost is that every team's release rides on the host's own build-test-deploy pipeline, so release cadence is shared. - **Runtime integration** flips this: each team ships on its own schedule, completely decoupled from the host's release train, but nothing checks at compile time that a remote's exposed API still matches what the host expects, and dependency versions have to be reconciled live in the browser instead of by a bundler ahead of time. ## Failure modes Failure modes differ accordingly. | Style | When they surface | The catch | |---|---|---| | Build-time integration's failures | show up early and cheaply — a broken import fails a PR build, a type mismatch fails `tsc` | but they can block unrelated teams whenever the shared pipeline breaks | | Runtime integration's failures | show up late and expensively — in production, as a user-facing incident | because there's no compiler standing between a breaking change in one team's code and a user hitting it | A remote that renames an exported prop, or a remote that requires a newer version of a 'shared, singleton' library than the host provides, will not fail anyone's build; it will fail in a live browser, often intermittently, and has to be caught by monitoring, contract tests, or manual QA instead. ## Where it shows up A concrete real-world illustration: a company like **IKEA** or **Zalando** publishing shared component libraries as versioned npm packages that product teams import and bundle is build-time integration, even inside a broader system loosely called 'microfrontends' — a fix only reaches users once each consuming team bumps the version and redeploys. By contrast, platforms like **Spotify's** desktop client and **DAZN's** frontend, which are publicly documented as adopting Module Federation, moved to runtime integration specifically once they had enough independently-owned frontend teams that a shared build-time release train became a bottleneck. Neither style is universally correct; the choice trades organizational deploy independence against compile-time correctness, and mature systems often use both styles for different boundaries within the same product, build-time for tightly coupled pieces, runtime for loosely coupled, independently-owned feature areas.