mfe-boundary-routing

URL routing ownership — shell vs micro-frontend

Contents

• Principle
• Shell: dynamic first-level routes (main goal)
• Micro-frontend: hardcoded internal routes (expected)
• Shell platform events vs domain events
• Vertical vs horizontal split
• Violation signals
• Adding or removing a micro-frontend

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

Principle

Split routing responsibility by URL depth, not by who implements the router API:

URL depth	Owner	Example
First segment (top-level path)	Shell	/, /catalog, /checkout
Second segment onward	Micro-frontend	/catalog/product/sku-123, /checkout/shipping

The shell answers only: which MFE loads for this top-level area?
The MFE answers: what happens inside that area?

Navigation style is flexible. Use <a href>, React Router <Link>, navigate(), Angular Router, or full page loads — as long as changing the first segment loads the correct remote and deeper segments stay inside the owning MFE.

---

Shell: dynamic first-level routes (main goal)

The shell should load only first-level URLs from a runtime manifest (routes.json or equivalent) plus remote URLs (remotes.json). That way:

• Adding or removing an MFE updates configuration — not shell application code
• No shell redeploy is required when an existing MFE adds internal pages (/catalog/product/:id, /catalog/sale) — those routes are owned and deployed by the MFE team

[
  { "path": "/", "scope": "home_mfe", "module": "./HomeApp", "navLabel": "Home" },
  { "path": "/catalog/*", "scope": "catalog_mfe", "module": "./CatalogApp", "navLabel": "Catalog" }
]

The shell maps each entry to one remote mount (wildcard /* hands all deeper paths to that MFE). Nav labels can also come from the manifest.

Do not in the shell:

• Register domain sub-routes (/catalog/product/:id, /checkout/shipping)
• Hard-code per-MFE routes in App.tsx when a manifest could list them instead