Podstawy Module Federation

Module Federation umożliwia aplikacji JavaScript ładowanie i wykonywanie w czasie działania kodu z innej, niezależnie wdrażanej aplikacji. Wzorzec ten powstał w Webpack 5, a obecnie można go również realizować za pomocą natywnych map importów i dynamicznego importu.

Duże organizacje dzielą monolity na wiele niezależnie wdrażanych „mikrofrontendów” — aplikację powłoki oraz kilka aplikacji funkcjonalnych. Module Federation pozwala powłoce ładować poszczególne funkcje na żądanie, bez łączenia ich podczas kompilacji.

W Webpack 5 aplikacja hosta deklaruje element remotes (inne aplikacje, z których korzysta), a aplikacje zdalne deklarują element exposes (oferowane elementy). Podczas uruchamiania środowisko wykonawcze pobiera niewielki manifest z każdej aplikacji zdalnej, a następnie pobiera fragmenty, gdy host je importuje.

Bez Webpack ten sam pomysł działa z mapami importów wskazującymi zdalne bundlowane moduły ESM oraz z dynamicznym importem do ich ładowania. Mapa importów hosta zawiera wpis "feature-cart": "https://cart-team.example.com/entry.js"; wywołanie import("feature-cart") ładuje najnowszą wdrożoną wersję.

Bez koordynacji każda aplikacja zdalna dostarczałaby własną kopię React. Narzędzia federacji umożliwiają deklarowanie współdzielonych zależności — pierwsza aplikacja zdalna, która załaduje React, udostępnia go wszystkim pozostałym. Podejścia natywne używają map importów, aby kierować każdą aplikację zdalną do tego samego adresu URL React.

Każdy zespół jest właścicielem swojej aplikacji zdalnej i wdraża ją wtedy, gdy chce. Host nigdy nie jest ponownie budowany; pobiera nowe wersje przy kolejnym ładowaniu strony (lub po unieważnieniu pamięci podręcznej). Całkowicie rozdziela to cykle wydań.

Aplikacje zdalne należy przypinać do wersjonowanych adresów URL (/v1/entry.js, /v2/entry.js), aby aktualizacja hosta była zamierzona, a nie niejawna. Niektóre zespoły używają dopasowywania wersji semver na poziomie mapy importów za pomocą narzędzi takich jak JSPM.

Federacja zwiększa złożoność działania w czasie wykonywania: oznacza więcej żądań sieciowych, utrudnia debugowanie między źródłami i niesie ryzyko niezgodności współdzielonych zależności. Należy jej używać, gdy niezależne wdrażanie jest rzeczywiście potrzebne; w mniejszych projektach pojedyncza kompilacja jest prostsza i szybsza.

Awaria jednego zdalnego modułu nie powinna powodować awarii hosta. Należy opakować dynamiczne importy w granice błędów (React) lub bloki try/catch (vanilla) i wyrenderować zastępczy interfejs, gdy zdalny moduł ulegnie awarii. Powłoka aplikacji pozostaje funkcjonalna, nawet jeśli dana funkcja jest tymczasowo niedostępna.

Eksporty zdalnego modułu nie mają informacji o typach dostępnych w czasie kompilacji po stronie hosta. Należy wygenerować współdzielone typy TypeScript w osobnym pakiecie używanym przez obie strony albo zastosować walidację w czasie działania (Zod, io-ts) na granicy federacji.

Natywna federacja (import maps + ESM) jest prostsza i oparta na standardach, ale nie zapewnia koordynacji współdzielonych zależności dostępnej w Webpack. Należy wybrać Webpack/Module Federation w przypadku złożonych aplikacji z wieloma współdzielonymi zależnościami, a rozwiązanie natywne w prostszych konfiguracjach mikrofrontendów.

W3C bada bogatsze mechanizmy ładowania modułów, które zwiększyłyby możliwości natywnej federacji — w tym umożliwiłyby lepsze uzgadnianie współdzielonych zależności. Obecnie należy traktować import maps jako fundament, a narzędzia do federacji nakładać na tę podstawę.

Jaki jest główny powód używania Module Federation w dużej aplikacji?

Module Federation pozwala hostowi ładować w czasie działania kod z niezależnie wdrażanych zdalnych modułów. Narzędzia Webpack 5 dodają uzgadnianie współdzielonych zależności, a natywna federacja korzysta z import maps i dynamicznego importu. To rozwiązanie jest przeznaczone dla architektur mikrofrontendowych z wieloma zespołami; w zamian za niezależność wdrażania trzeba zaakceptować większą złożoność.