mfe-boundary-toolchain

MFE boundary rules — toolchain patterns

Contents

• URL routing — shell first segment, MFE below (Rule 7)
• Rule 2 — Exposes a minimal API surface to its container
• Rule 3 — Hides implementation details behind an API contract
• Rule 5 — Deploys independently without coordination
• Rule 7 — Is coarse-grained enough to prevent context leakage
• Governance extension — feature flags scope
• Governance extension — edge strategy
• Governance extension — SSR ownership and composition
• Governance extension — fitness functions in monorepos

Version: 1.3 | Skill: reviewing-mfe-boundaries | Source: Building Micro-Frontends (O'Reilly)

Toolchain-specific code patterns for each boundary rule. Load this file when the user is working with a specific framework or when a rule violation needs framework-specific guidance. For principle definitions and violation signals, see rules-core-critical.md and rules-core-standard.md.

URL routing — shell first segment, MFE below (Rule 7)

Principle: shell loads first segment from a dynamic manifest; MFE hardcodes deeper paths. Navigation API is flexible. Shell handles shell:* platform events only. See routing-ownership.md.

// React Router — shell
<Route path="/catalog/*" element={<RemoteMount scope="catalog_mfe" />} />

// React Router — catalog remote (basename matches shell prefix)
<BrowserRouter basename="/catalog">
  <Routes>
    <Route path="/" element={<ProductList />} />
    <Route path="/product/:productId" element={<ProductDetail />} />
  </Routes>
</BrowserRouter>

// Angular — shell first segment
{ path: 'catalog', loadChildren: () => loadRemoteModule('catalog', './routes') }
// catalog/routes.ts (catalog team): { path: 'product/:id', component: ProductDetailComponent }

// Single SPA — shell first segment via activeWhen prefix
registerApplication({
  name: 'catalog',
  app: () => import('catalog/main'),
  activeWhen: (location) => location.pathname.startsWith('/catalog'),
})
// catalog/main mounts its own router for /catalog/product/:id