Grundlagen der Module Federation

Module Federation ermöglicht es einer JavaScript-Anwendung, zur Laufzeit Code aus einer anderen, unabhängig bereitgestellten Anwendung zu laden und auszuführen. Das Muster entstand in Webpack 5 und ist inzwischen auch über native Import Maps und Dynamic Import möglich.

Große Organisationen teilen Monolithen in mehrere unabhängig bereitgestellte „Micro-Frontends“ auf – einen Shell-Host und mehrere Feature-Anwendungen. Module Federation ermöglicht es der Shell, jedes Feature bei Bedarf zu laden, ohne sie zur Build-Zeit gemeinsam zu bündeln.

In Webpack 5 definiert der Host remotes (andere zu konsumierende Apps), während Remotes exposes definieren (was sie anbieten). Die Runtime ruft beim Start ein kleines Manifest von jedem Remote ab und lädt Chunks herunter, sobald der Host sie importiert.

Ohne Webpack funktioniert dasselbe Prinzip mit Import Maps, die auf entfernte ESM-Bundles zeigen, und mit Dynamic Import zum Laden. Die Import Map des Hosts enthält "feature-cart": "https://cart-team.example.com/entry.js"; import("feature-cart") lädt die zuletzt bereitgestellte Version.

Ohne Abstimmung würde jedes Remote seine eigene Kopie von React ausliefern. Federation-Tools ermöglichen die Deklaration gemeinsamer Abhängigkeiten – das erste Remote, das React lädt, stellt es allen anderen zur Verfügung. Native Ansätze verwenden Import Maps, um jedes Remote auf dieselbe React-URL zu verweisen.

Jedes Team ist für sein Remote verantwortlich und kann es jederzeit bereitstellen. Der Host muss nie neu gebaut werden; beim nächsten Laden der Seite übernimmt er neue Versionen (oder dies geschieht über Cache-Busting). Dadurch werden die Release-Zyklen vollständig voneinander entkoppelt.

Fixieren Sie Remotes auf versionierte URLs (/v1/entry.js, /v2/entry.js), damit ein Upgrade des Hosts bewusst und nicht implizit erfolgt. Einige Teams verwenden über Tools wie JSPM eine Semver-Abstimmung auf Ebene der Import Map.

Federation bringt zusätzliche Komplexität zur Laufzeit mit sich: mehr Netzwerkanfragen, schwierigeres Debugging über Origins hinweg und das Risiko inkompatibler gemeinsamer Abhängigkeiten. Verwenden Sie es, wenn Sie tatsächlich unabhängige Bereitstellungen benötigen; bei kleineren Projekten ist ein einzelner Build einfacher und schneller.

Der Absturz eines einzelnen Remotes darf den Host nicht mit herunterreißen. Umschließen Sie dynamische Importe mit Fehlergrenzen (React) oder try/catch (vanilla) und rendern Sie eine Fallback-Oberfläche, wenn ein Remote fehlschlägt. Die Shell bleibt funktionsfähig, selbst wenn ein Feature vorübergehend gestört ist.

Für von Remotes exportierte Werte stehen dem Host zur Kompilierzeit keine Typinformationen zur Verfügung. Generieren Sie gemeinsame TypeScript-Typen in einem separaten Paket, das von beiden Seiten verwendet wird, oder nutzen Sie Laufzeitvalidierung (Zod, io-ts) an der Federation-Grenze.

Native Federation (Import Maps + ESM) ist einfacher und basiert auf Standards, bietet aber nicht Webpacks Koordination gemeinsam genutzter Abhängigkeiten. Wählen Sie Webpack/Module Federation für komplexe Anwendungen mit vielen gemeinsam genutzten Abhängigkeiten und Native Federation für einfachere Micro-Frontend-Setups.

Das W3C untersucht leistungsfähigere Primitive zum Laden von Modulen, die Native Federation ausbauen würden – einschließlich einer besseren Aushandlung gemeinsam genutzter Abhängigkeiten. Betrachten Sie Import Maps heute als Grundlage und setzen Sie darauf Ihre Federation-Tools auf.

Was ist die wichtigste Motivation für den Einsatz von Module Federation in einer großen Anwendung?

Mit Module Federation kann ein Host zur Laufzeit Code aus unabhängig bereitgestellten Remotes laden. Die Tools von Webpack 5 ermöglichen die Aushandlung gemeinsam genutzter Abhängigkeiten; Native Federation verwendet Import Maps und dynamische Importe. Setzen Sie Module Federation für Micro-Frontend-Architekturen mit mehreren Teams ein und akzeptieren Sie die zusätzliche Komplexität als Gegenleistung für unabhängige Bereitstellungen.