{
  "id": 10175292,
  "title": "The hard part of micro frontends is the contract, not the bundler",
  "url": "https://urgent.news/2026/09/27/the-hard-part-of-micro-frontends-is-the-contract-not-the-bundler",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-27T08:25:52.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/theadnansaleem/the-dashboard-is-blank-for-some-users-f2l"
  },
  "original_language": "en",
  "account": "Writing micro frontends is challenging, not due to the bundler configuration, but the contractual agreement between the shell and remote modules. The most recent write-ups on Module Federation stop at the configuration, with the actual contract being overlooked. In the source example, the writer describes a government events platform frontend constructed as a single React application, released as a single unit. Teams had to wait for the slowest member to complete their work before any release, leading to a bottleneck. The objective was to enable teams to deploy independently without constantly coordinating meetings.\n\nWith Module Federation, the shell loads remote modules at runtime, which is where the guarantees from the build time vanish. In a monolithic structure, a discrepancy between parts of the application would result in a build error, preventing the shipment of the faulty version. However, after the split, the shell and remote are constructed through different pipelines, possibly weeks apart. Mismatches are no longer flagged as build errors but rather as blank panels in production, shared libraries initialized multiple times, or hooks being called on the wrong React copy.\n\nTo mitigate these issues, the boundary between the shell and remote modules was made explicit, and versioned. Each remote declares what it exposes and what it expects, such as the props of the exposed module, the shape of events it emits, and the range of shared dependencies it was built against. The shell checks this range before mounting any component. If a remote is outside these boundaries, the shell refuses it, instead rendering a defined fallback.\n\nThis approach ensures that failures are caught at load time, in one place, with a message pinpointing the faulty remote and expected range. It also makes independent deploys straightforward; a team can release their remote as soon as it meets the contract. The shared dependencies no longer become an unknown factor, as React and the design system are declared as shared with explicit ranges, providing clarity on which version is loaded. Consequently, the release cycle improved by approximately 40%, with most of the time saved not being in the build process but in the eliminated waiting period.",
  "summary": "Most Module Federation write-ups stop at the config. You add the plugin, you name a few exposes and remotes, the demo loads a button from another build, and the post ends. That part takes an afternoon. The part that decides whether this survives contact with several teams is the contract between the shell and the remotes. What we were splitting A React frontend for a government events platform,…",
  "key_points": [
    "Contractual agreement between shell and remote modules is the main challenge in micro frontends.",
    "Module Federation loads remote modules at runtime, removing build time guarantees.",
    "Explicitly defined and versioned boundaries between shell and remote modules mitigate issues."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}