Microfrontends

A host is the app that loads pieces from other apps; a remote is the app that shares its pieces. Webpack lets the host fetch and run the remote's code straight from the browser, without both being built together.

Path-based routing uses the real URL path and needs server/CDN config to serve the app for every path; hash-based routing puts the route after a # so the browser never asks the server for it, but it looks less clean and hurts SEO.

Build-time means you bake all the pieces together into one app before you ship it, like baking ingredients into one cake. Runtime means the browser loads separate pieces live, like assembling a meal from dishes served at the table.

Singleton means every microfrontend uses one shared copy of a library loaded once on the page. Scoped means each microfrontend ships and uses its own private copy. Singleton saves download size but couples apps; scoped isolates apps but repeats code.

A contract is the agreed set of inputs (props), outputs (events), and shared visual rules (design tokens) two teams promise not to change without warning, so each team can update its own code without breaking the others.

The server (or a CDN edge) fetches each microfrontend's HTML piece and stitches them into one page before sending it to the browser, so the browser gets a complete, already-composed page instead of empty boxes that JavaScript fills in later.

'exposes' is a remote saying 'here's what I'm sharing and its nickname'; 'remotes' is a host saying 'here's a friend's address I want to fetch code from.' 'filename' just names the small file that makes the connection work.

Shared deps are libraries (like React) that separately-built apps agree to reuse one copy of instead of each shipping their own. Marking one 'singleton' means only one copy is ever allowed to run at once; if the versions genuinely clash, the app can crash or silently duplicate the library, either way it's risky.

The link isn't a normal <a> that reloads the page; the shell's router intercepts the click, updates the browser URL with the History API, notices the new path belongs to a different microfrontend, unmounts the old one, and mounts the new one — all without asking the server for a new page.

The team's code gets pulled into the main app during its build, so nothing goes live until the whole app is rebuilt and redeployed together — teams can't ship on their own schedule.

The host page loads a small manifest file from the microfrontend's server that tells the browser where to fetch its actual code, then the browser downloads and runs that code on the spot and slots it into the page.

The runtime looks at every version range each app asked for, tries to find one already-loaded version that satisfies all of them, and uses that. If none satisfies everyone, or if you set stricter rules, it either loads a second separate copy for the mismatched app or throws an error, depending on your configuration.

Every deploy must keep working with old and new versions of everyone else at the same time, because you never know exactly who's running what. If a team ships a change that only works with a version nobody else has deployed yet, things break for real users mid-rollout.

They use the server-composed approach for parts search engines need to read, like product details, and the client-mounted approach for parts that need heavy interactivity, like an add-to-cart form, because no single method is best at both. The cost is now managing two different composition systems and keeping them in sync on one page.

With build-time integration, undoing a bug means redeploying the whole combined app to an older version, which affects everyone at once. With runtime integration, the team that broke it can usually just redeploy their own piece, so the fix or rollback is smaller and faster.

You'll see weird bugs like broken shared state, theme/context not applying somewhere, or a hooks crash -- but only for one part of the page, not everywhere. Checking the browser's network tab shows the same library file downloaded twice, which confirms two separate copies are running.

Draw the lines between microfrontends the same way you'd draw the lines between teams — one team, one clear piece of the product. If a boundary forces two teams to constantly touch the same fragment, you'll get either confusing shared code or constant coordination meetings.

You need something better than tribal knowledge — a checked-in, machine-readable registry of who owns which URL, automated checks that stop two teams from claiming the same route by accident, and a real process for handing off or splitting ownership when teams reorganize.

The mapping tells the shell which team's code to load for a given URL, so each team can build and deploy independently. Shared elements like a global header that appear on every page are usually owned by a separate, always-mounted piece rather than by any single route-owning team.

Don't flip the switch all at once. Send both the old and new versions of the data for a while, tell other teams the old one is going away on a date, watch to see who's still using it, and only remove the old version once nobody is.

Shadow DOM keeps each microfrontend's CSS and internal markup from leaking into or being affected by the rest of the page, like a bubble around its styles and structure. But it does not stop its JavaScript from touching the same page-wide window object, unlike an iframe which blocks that too.

A static remote's address is baked into the host when it's built. A dynamic remote's address is looked up while the app is actually running, for example fetched from a server, so the host doesn't need to be rebuilt just to point at a different remote.

If the piece of a page that comes from another team's app fails to load, you probably have a broken link to their code, a version clash between shared libraries, or a bug in their code. The fix is to build the page so one missing piece shows a small fallback instead of breaking the whole page.

The microfrontend's internal router must not fight the shell's top-level router over control of the browser's URL and back button — usually the MFE's router is scoped to only the part of the path under its own prefix, and both must agree on one shared history stack instead of each keeping a separate idea of 'where we are.'

If two sections are built with totally different tech, teams, or release cycles, and users rarely bounce between them quickly, it's often simpler and safer to just let the browser do a normal page load between them instead of forcing them into one shared client-side router.

If the browser or a CDN caches the old file at that same web address, users can keep getting yesterday's broken code even after the team ships a fix, because nothing tells the cache the file changed.

An import map is a config that tells 'import react' to actually fetch a specific URL. Overriding one entry lets you redirect just that library to a different file -- like a staging build or hotfix -- without touching or rebuilding any of the apps that import it.

Each team that depends on another team's fragment writes down exactly what they expect from it, and the producing team runs those written expectations as automated checks before every deploy — so a breaking change gets caught in CI instead of in production. It can't catch a new team you didn't know was depending on you.

If the teams don't actually need to ship on different schedules, or the org can't yet handle the extra operational work like version conflicts and monitoring many moving pieces, the simpler build-time setup is usually the better choice.