mfe-boundary-code-patterns

Code generation patterns by rule

Toolchain-specific examples for applying the boundary rules when generating MFE code. Organised by concern so you can load only what you need. React, Angular / Native Federation, Vue, and Single SPA are covered where they differ.

Contents

• URL routing — shell first segment only; MFE owns depth below (Rule 7)
• Shell platform events — allowed; domain events in shell — not (Rules 4, 7)
• Shell mounting — always include a fallback in the shell, not inside the micro-frontend (Rule 6)
• Props — pass identifiers, not domain objects (Rule 2)
• Same-page communication (horizontal split) — event emitter between peers, never shared state (Rule 4)
• Shell platform bus — chrome only (Rules 4, 7)
• Cross-area navigation and data — first segment switches MFE; depth stays in MFE (Rules 4, 7)

URL routing — shell first segment only; MFE owns depth below (Rule 7)

• Shell: load only first-level paths from a runtime manifest (routes.json + remotes.json) so adding/removing an MFE does not require shell code changes or redeploy for MFE-internal pages
• MFE: hardcoded internal routes are expected (/product/:id under /catalog); new sub-pages are MFE-only deploys
• Navigation implementation: flexible (<a>, <Link>, navigate(), etc.) — enforce URL depth ownership, not a specific router API
• Cross-area navigation: change the first URL segment; deeper segments stay inside the owning MFE

// ✓ Shell — manifest-driven first segment (wildcard → remote)
// routes.json: { "path": "/catalog/*", "scope": "catalog_mfe", "module": "./CatalogApp" }
routes.map((r) => <Route key={r.scope} path={r.path} element={<RemoteMount ... />} />)

// ✓ Catalog MFE — hardcoded routes under basename (no shell change when adding pages)
<BrowserRouter basename="/catalog">
  <Routes>
    <Route path="/product/:productId" element={<ProductDetail />} />
  </Routes>
</BrowserRouter>

// ✗ Shell — domain sub-route
<Route path="/catalog/product/:productId" element={...} />