Reaktive Micro-Frontends mit Webpack Module Federation

Große Produktoberflächen sind selten noch ein einziges Frontend. Der Checkout, Dashboards, Einstellungen sowie die umgebenden Elemente gehören oft verschiedenen Teams, von denen jedes sein eigenes Backlog, technische Verpflichtungen und Release-Calendar hat. Diese Struktur wird in der Regel als Micro-Frontends bezeichnet: unabhängig verwaltete UI-Bereiche, die dennoch wie ein einziges Produkt erscheinen – das clientseitige Äquivalent zu Microservices.

Lange Zeit war die React-Tooling-Lösung für dieses Muster unpraktisch. Organisationen nutzten entweder ein einziges riesiges SPA-Bundle oder integrierten separate Apps in Iframes und akzeptierten die damit verbundenen Kosten. Module Federation in Webpack 5 machte einen dritten Ansatz praktikabel: unabhängig entwickelte und bereitgestellte JavaScript-Apps, die zur Laufzeit in einem Browserdokument zusammengeführt werden. Zu verstehen, was diese Funktion leistet – und warum sie die älteren Lösungswege verdrängt hat – ist für alle wichtig, die mehrerteamsbasierte React-Systeme entwerfen.

Das Problem vor Module Federation

Vor der Einführung von Federation hatten Teams, die eine unabhängige Bereitstellung der Frontend-Komponenten wünschten, nur begrenzte Möglichkeiten.

Standardmäßig wurde ein monolithisches SPA verwendet: ein Repository, ein Pipeline-Prozess und eine einzige Bereitstellung. Dieses Modell eignet sich für kleine Teams. Wenn die Verantwortlichkeiten sich verteilen, steigt der Widerstand. Jede Funktion teilt sich denselben Build-Prozess. Die Kompilierzeit nimmt mit der Größe des Codebases zu. Eine Regression in einem Bereich kann die Veröffentlichungsprozesse eines anderen Teams blockieren. Die Abstimmung der Bereitstellungen bei vielen Teams wird zu einer eigenen Form des Projektmanagements.

Iframes waren eine weitere weit verbreitete Lösung. Das Einbetten einer vollständigen Unteranwendung in eine übergeordnete Seite ermöglichte tatsächliche Unabhängigkeit bei der Bereitstellung, weshalb viele Unternehmen sie nutzten. Die Nachteile häuften sich jedoch schnell an:

• Die Isolation ist absolut. Styles, DOM und JavaScript-Kontexte vermischen sich nicht. Der Austausch von Zuständen, die Koordination von Daten oder die Durchsetzung einer einheitlichen Designsprache zwischen Eltern- und Kindkomponenten erfordern aufwendige Implementierungen anstelle einfacher Prop-Übertragung.
• Abhängigkeiten duplizieren sich. Jedes Frame lädt oft seine eigenen React-Instanzen, gemeinsam genutzte Bibliotheken sowie CSS. Die Nutzer laden dieselben Daten immer wieder herunter.
• Die Benutzererfahrung leidet. Scrollen, Fokussierung, Anpassung der Größe, Deep Links sowie die Historie zwischen Frame-Grenzen erfordern spezielle Lösungen und wirken dennoch unzureichend.
• SEO und Barrierefreiheit leiden. In Frames enthaltener Inhalt ist schwieriger zu indizieren und weniger konsistent für assistive Technologien.
• Die Kommunikation beschränkt sich auf Nachrichten. Der Datenaustausch zwischen Frames erfolgt über postMessage sowie selbst entwickelte Protokolle – es gibt weder gemeinsamen Speicher noch einen gemeinsamen React-Kontext.

Iframes lösten das Problem der unabhängigen Bereitstellung, schufen aber ein noch größeres Problem bei der reinen Integration. Was fehlte, war Unabhängigkeit bei der Erstellung und Bereitstellung ohne Aufgabe eines einheitlichen Dokumenten-User Experiences.

Was ist Module Federation?

Module Federation, das mit Webpack 5 eingeführt wurde, ermöglicht es getrennt entwickelten und bereitgestellten JavaScript-Anwendungen, Code zur Laufzeit statt zur Kompilierzeit zu teilen.

In der Praxis können mehrere Anwendungen – von verschiedenen Teams, Pipelines und Veröffentlichungskanälen – im Browser als ein einziges Produkt zusammengeführt werden. Eine Anwendung stellt einen Komponenten, eine Route oder ein Hilfsprogramm bereit; eine andere nutzt dieses, als würde es im selben Paket liegen, ohne dass die Nutzungsanwendung neu kompiliert werden muss, wenn sich der Anbieter ändert.

Diese Laufzeit-Komposition bildet heute die übliche technische Grundlage für React-Micro-Frontends.

Wie es funktioniert: Hosts, Remotes und gemeinsame Abhängigkeiten

Federation definiert zwei Rollen:

• Ein Host lädt Code, der an anderer Stelle veröffentlicht wurde. Oft handelt es sich dabei um die Schale, die die UI anderer Teams einbindet.
• Ein Remote veröffentlicht Module für andere: Seiten, Komponenten, Hooks oder Hilfsfunktionen.

Eine Anwendung kann beides sein: Sie stellt einige Module zur Verfügung, während sie andere konsumiert.

Remotes deklarieren die Exporte in der Webpack-Konfiguration; Hosts deklarieren, welche Remotes geladen werden sollen und welche Symbole importiert werden müssen. Das Laden erfolgt im Browser über eine Remote-Entry-URL. Für den Host-Build ist die Quelle des Remotes nicht notwendig – lediglich ein stabiler Einstiegspunkt, den er beim Starten der Anwendung abrufen kann.

Gemeinsame Abhängigkeiten vervollständigen das Bild. Wenn sowohl der Host als auch der Remote-Teil React benötigen, kann Federation angewiesen werden, eine einzige React-Instanz zu teilen anstelle von zwei. Dadurch entfällt die Duplikation im Stil eines Iframes, während Teams dennoch bei Bedarf unterschiedliche Versionen verwenden können.

Module Federation gegen Iframes

Dieser Vergleich erklärt, warum so viele Teams auf Iframes verzichteten, sobald Federation ausgereift war. Man behält die Deploy-Unabhängigkeit, die Iframes attraktiv machte, ohne auf Qualität der Integration zu verzichten. Die Remote-Teile ergänzen den DOM des Hosts, teilen eine JavaScript-Welt und können Provider, State-Strukturen sowie Design-System-Pakete wiederverwenden – Aufgaben, die über die Grenzen eines Iframes schwierig oder unmöglich waren.

Warum große Teams es nutzen

Kleine Produkte benötigen selten diese Komplexität. Organisationen mit vielen Frontend-Teams nutzen Federation, um strukturelle Engpässe zu beseitigen:

• Unabhängige Bereitstellung. Ein Remote-Team kann eine Korrektur bereitstellen, ohne die Artefakte aller anderen Teams neu erstellen zu müssen.
• Teamautonomie. Jede Gruppe behält ihren eigenen Arbeitsrhythmus, ihre CI-Infrastruktur sowie – innerhalb bestimmter Grenzen – die Wahl der Tools bei.
• Schnellere Builds. Getrennte Remotes bedeuteten, dass kleine Änderungen keinen gesamten Monolithen neu kompilieren müssen.
• Schrittweise Modernisierung. Legacy-Systeme können neue Remotes Stück für Stück hinzufügen, anstatt auf einen einzigen Umstieg zurückzugreifen.
• Flexibilität des Technologiestacks. Das Teilen eines Frameworks ist am einfachsten, doch Teams überbrücken manchmal große Versionsunterschiede – oder mit mehr Aufwand auch unterschiedliche Frameworks – durch Federation-Grenzen.

Echte Anwendungsfälle

Handelswebsites ermöglichen es oft den Teams für Kataloge, Bestellabläufe und Konten, eigene Remote-Umgebungen zu nutzen. SaaS-Produkte liefern Dashboard-Widgets oder Einstellungspanelle von Funktionsteams – ohne für jede Änderung die Kernstruktur öffnen zu müssen. Migrationen trennen Teile eines herkömmlichen SPAs in separate Remote-Umgebungen ab, während die alte Oberfläche weiterhin läuft.

Zusammenfassung der wichtigsten Vorteile

Der Wert von Federation lässt sich in einer kurzen Liste zusammenfassen: echte, unabhängige Bereitstellbarkeit, eine gemeinsame Laufzeitumgebung, die doppelte Bibliotheken sowie instabile Kommunikation zwischen Anwendungen vermeidet, und ein Benutzererlebnis, das weiterhin wie eine einzige Anwendung wirkt. Es bietet die versprochene Autonomie der Iframes – ohne die Kosten für Integration und Leistungseinschränkungen.

Fazit

Der Übergang von Iframes zu Module Federation ist Teil einer größeren Reifung der Frontend-Architektur: Unabhängige Bereitstellung und eine kohärente Benutzeroberfläche müssen nicht länger Gegensätze sein. Webpack 5 machte diese Kombination für Organisationen, die stark auf React setzen und deren Anwendungen bereits zu groß für ein einzelnes Bundle geworden waren, umsetzbar. Da die Adoption zunimmt und Tools wie Rspack sowie Module Federation 2.0 dieselben Konzepte der Laufzeitteilung erweitern, hilft das Verständnis dafür, warum dieser Wandel stattfand, jedem, der große React-Systeme entwirft, dabei, bewusst Grenzen für die Verantwortlichkeiten festzulegen, anstatt automatisch auf Iframes oder immer größere Monolithen zurückzugreifen.

Probieren Sie es selbst aus

Ein minimales Host/Remote-Beispiel ist unter react_module_federation verfügbar.

Klonen Sie es lokal:

git clone https://github.com/ModithaM/react_module_federation.git
cd react_module_federation

Starten Sie zunächst das Remote, damit seine öffentliche Eingangsstelle bereits Daten bereitstellt, bevor der Host nach Modulen fragt:

cd remote
npm install
npm start

In einem zweiten Terminal starten Sie den Host:

cd host
npm install
npm start

Öffnen Sie den Host im Browser; er sollte laufend entfernte Komponenten laden und die oben beschriebene Beziehung veranschaulichen. Die Reihenfolge ist wichtig: Ein allein gestarteter Host hat nichts zu laden, bis die entfernten Komponenten verfügbar sind – das erinnert nützlich daran, dass die Unabhängigkeit von Federation weiterhin davon abhängt, ob die entfernten Komponenten beim Start des Shells erreichbar sind.