Versionierung, Deployment und Orchestrierung

Der wichtigste Vorteil von Module Federation ist die unabhängige Bereitstellung: Ein Team kann sein remote aktualisieren, testen und bereitstellen, ohne sich mit den Teams der Hosts abzustimmen oder eine erneute Bereitstellung der Hosts auszulösen. Der host übernimmt die Änderungen automatisch, sobald er remoteEntry.js beim nächsten Laden von der URL des remote abruft.

Statt remoteEntry.js unter einer festen URL bereitzustellen, die sich bei jeder Bereitstellung ändert, sollten Sie einen Content-Hash in die URL aufnehmen: remoteEntry.[hash].js. Dadurch wird jede Bereitstellung unveränderlich. Alte URLs funktionieren weiterhin, und der host verweist auf den neuen Hash, sobald er auf die neue Bereitstellung aktualisiert wurde. Unveränderliche URLs ermöglichen aggressives Caching über ein CDN.

Da der host Remotes über eine URL ermittelt, können Sie A/B-Tests auf Infrastrukturebene umsetzen: Stellen Sie verschiedenen Benutzern unterschiedliche remoteEntry.js-URLs bereit, die auf verschiedene Versionen des remote verweisen. Dadurch werden echte Canary-Bereitstellungen für Micro-Frontends möglich, ohne dass die Anwendung Feature-Flag-Logik im Code benötigt.

Statt Remote-URLs in der Webpack-Konfiguration fest zu hinterlegen, ruft der host beim Start ein JSON-Manifest ab: GET /federation-manifest.json returns { buttonApp: 'https://cdn.example.com/button/remoteEntry.abc123.js' }. Um die vom host verwendete Version zu aktualisieren, passen Sie das Manifest an – ein erneuter Build des host ist nicht erforderlich.

Wenn eine Bereitstellung des remote eine Regression einführt, ist ein Rollback sofort möglich: Aktualisieren Sie federation-manifest.json so, dass es auf die vorherige remoteEntry.js-URL verweist. Der host verwendet bei der nächsten Anfrage sofort wieder die alte Version. Kein erneuter Build des host, kein Rollback des host, keine Abstimmung erforderlich.

Module Federation 2.0 (das Paket @module-federation/enhanced) bringt wesentliche Verbesserungen: eine bessere TypeScript-Unterstützung mit automatischer Typgenerierung aus Remote-Manifesten, eine Runtime-Plugin-API für benutzerdefinierte Ladelogik sowie eine verbesserte Verwaltung des Shared Scope für komplexe Szenarien der Versionsverhandlung.

Das Paket vite-plugin-federation bringt Module Federation in Vite-basierte Projekte und verwendet eine ähnliche Konfigurations-API wie Webpacks ModuleFederationPlugin. Es ist sowohl mit Vite-Remotes als auch mit Webpack-Hosts kompatibel (und umgekehrt), sodass Teams schrittweise zu Vite migrieren können, ohne Module Federation aufgeben zu müssen.

Für hochdynamische Architekturen können Sie Remote-URLs vollständig zur Laufzeit konfigurieren: import(remoteRegistry[featureName]), wobei remoteRegistry durch einen API-Aufruf befüllt wird. Dadurch werden Plugin-ähnliche Architekturen möglich, in denen neue Micro-Frontends hinzugefügt werden können, ohne die Shell-Anwendung neu zu bauen.

Die primäre Aufgabe der Shell-Anwendung ist die Orchestrierung: Sie liest das Remote-Manifest, initialisiert die Runtime von Module Federation, registriert Remote-Module unter benannten Routen und rendert abhängig von der aktuellen URL das passende Remote. Die Shell ist bewusst schlank — sie weiß, was geladen werden soll, nicht, wie es gerendert wird.

Fügen Sie dem Laden von Remotes ein Performance-Monitoring hinzu: Umschließen Sie Remote-Imports mit try/catch, um Ladefehler ordnungsgemäß zu behandeln, und rendern Sie eine Fallback-UI, wenn das Remote nicht verfügbar ist. Messen Sie die Zeit zum Herunterladen von remoteEntry.js und den Komponenten-Chunks und lösen Sie einen Alarm aus, wenn die Ladezeit des Remotes einen Schwellenwert überschreitet, was auf Probleme mit dem CDN hindeutet.

Eine ausgereifte CI/CD-Pipeline für Module Federation sieht folgendermaßen aus: Das Remote-Team committet → die CI erstellt das Remote → die unveränderliche Datei remoteEntry.[hash].js wird in das CDN hochgeladen → federation-manifest.json wird aktualisiert → der Host übernimmt beim nächsten Benutzeraufruf das neue Remote. Jeder Schritt ist automatisiert, und das Host-Team ist nie an Remote-Deployments beteiligt.

Was ist der schnellste Weg, ein fehlerhaftes Module-Federation-Remote-Deployment zurückzurollen?

Module Federation ermöglicht echte unabhängige Deployments: Remotes werden ohne neue Builds des Hosts bereitgestellt, und der Host erkennt neue Versionen automatisch. Verwenden Sie mit einem Content-Hash versehene Remote-URLs für unveränderliches CDN-Caching sowie ein dynamisches Manifest für eine flexible Versionsweiterleitung und sofortige Rollbacks. vite-plugin-federation bringt diese Möglichkeiten zu Vite, und dynamische Remote-Imports ermöglichen Plugin-ähnliche Architekturen. Die Shell orchestriert das Laden von Remotes und bleibt dabei bewusst schlank.