Wersjonowanie, wdrażanie i orkiestracja

Najważniejszą korzyścią Module Federation jest niezależne wdrażanie: zespół może zaktualizować, przetestować i wdrożyć swój remote bez koordynacji z zespołami hosta i bez wywoływania ponownego wdrażania hosta. Host automatycznie pobierze zmiany przy następnym załadowaniu remoteEntry.js z adresu URL remote.

Zamiast udostępniać remoteEntry.js pod stałym adresem URL (który zmienia się przy każdym wdrożeniu), należy umieścić w adresie URL hash zawartości: remoteEntry.[hash].js. Dzięki temu każde wdrożenie jest niezmienne — stare adresy URL nadal działają, a host odwołuje się do nowego hasha po zaktualizowaniu do nowego wdrożenia. Niezmienne adresy URL umożliwiają agresywne buforowanie w CDN.

Ponieważ host wyszukuje remotes za pomocą adresu URL, można wdrożyć testy A/B na poziomie infrastruktury: różnym użytkownikom udostępniać różne adresy URL remoteEntry.js (wskazujące różne wersje remote). Umożliwia to prawdziwe wdrożenia canary dla mikrofrontendów bez umieszczania logiki flag funkcji w kodzie aplikacji.

Zamiast wpisywać adresy URL remote na stałe w konfiguracji Webpacka, host pobiera przy uruchomieniu manifest JSON: GET /federation-manifest.json zwraca { buttonApp: 'https://cdn.example.com/button/remoteEntry.abc123.js' }. Aby zmienić używaną przez hosta wersję, wystarczy zaktualizować manifest — przebudowa hosta nie jest wymagana.

Gdy wdrożenie remote wprowadzi regresję, wycofanie jest natychmiastowe: należy zaktualizować federation-manifest.json tak, aby wskazywał poprzedni adres URL remoteEntry.js. Przy następnym cyklu żądania host od razu zacznie używać starej wersji. Nie jest potrzebna przebudowa hosta, wycofanie hosta ani koordynacja.

Module Federation 2.0 (pakiet @module-federation/enhanced) wprowadza istotne ulepszenia: lepszą obsługę TypeScriptu dzięki automatycznemu generowaniu typów na podstawie manifestów remote, interfejs API wtyczek uruchamianych w czasie działania na potrzeby niestandardowej logiki ładowania oraz ulepszone zarządzanie współdzielonym zakresem na potrzeby złożonych scenariuszy negocjowania wersji.

Pakiet vite-plugin-federation udostępnia Module Federation w projektach opartych na Vite, wykorzystując interfejs API konfiguracji podobny do Webpackowego ModuleFederationPlugin. Jest zgodny zarówno z remote opartymi na Vite i hostami opartymi na Webpacku, jak i odwrotnie, dzięki czemu zespoły mogą stopniowo migrować do Vite bez rezygnowania z Module Federation.

W przypadku wysoce dynamicznych architektur można skonfigurować adresy URL remote w całości w czasie działania: import(remoteRegistry[featureName]), gdzie remoteRegistry jest wypełniany na podstawie wywołania API. Umożliwia to tworzenie architektur przypominających wtyczki, w których można dodawać nowe mikrofrontendy bez przebudowy aplikacji shell.

Podstawowym zadaniem aplikacji shell jest orkiestracja: odczytuje ona manifest remote, inicjalizuje środowisko uruchomieniowe Module Federation, rejestruje moduły remote pod nazwanymi trasami i renderuje odpowiedni remote na podstawie bieżącego adresu URL. Shell jest celowo niewielki — wie, co załadować, ale nie wie, jak to renderować.

Do ładowania remote należy dodać monitorowanie wydajności: opakować importy remote w try/catch, aby poprawnie obsługiwać błędy ładowania (w przypadku niedostępności remote renderować zastępczy interfejs), mierzyć czas pobierania remoteEntry.js i fragmentów komponentów oraz generować alert, jeśli czas ładowania remote przekroczy ustalony próg (co może wskazywać na problemy z CDN).

Dojrzały potok CI/CD dla Module Federation wygląda następująco: zatwierdzenie zmian przez zespół remote → kompilacja remote przez CI → przesłanie niezmiennego pliku remoteEntry.[hash].js do CDN → aktualizacja federation-manifest.json → host pobiera nowy remote przy następnym żądaniu użytkownika. Każdy etap jest zautomatyzowany, a zespół hosta nigdy nie uczestniczy we wdrażaniu remote.

Jaki jest najszybszy sposób na wycofanie nieudanego wdrożenia remote Module Federation?

Module Federation umożliwia prawdziwie niezależne wdrażanie: remote są wdrażane bez przebudowy hosta, a host automatycznie wykrywa nowe wersje. Należy używać adresów URL remote z hashem treści, aby zapewnić niezmienne buforowanie w CDN, oraz dynamicznego manifestu na potrzeby elastycznego kierowania wersjami i natychmiastowego wycofywania zmian. vite-plugin-federation udostępnia te możliwości w Vite, a dynamiczne importy remote umożliwiają tworzenie architektur przypominających wtyczki. Shell orkiestruje ładowanie remote, pozostając celowo niewielki.