Nozioni di base sulla Module Federation

Module Federation consente a un’applicazione JavaScript di caricare ed eseguire a runtime il codice di un’altra applicazione distribuita in modo indipendente. Nato in Webpack 5, questo approccio è ora possibile anche tramite import map native e import dinamici.

Le organizzazioni di grandi dimensioni suddividono i monoliti in più "micro-frontend" distribuiti in modo indipendente: un host shell più diverse applicazioni funzionali. Module Federation consente all’host di caricare ogni funzionalità su richiesta, senza unirle durante la build.

In Webpack 5, l’host dichiara i remotes (le altre app da utilizzare) e i remoti dichiarano gli exposes (ciò che offrono). Il runtime recupera un piccolo manifest da ogni remoto all’avvio e scarica i chunk quando l’host li importa.

Senza Webpack, la stessa idea funziona con import map che puntano a bundle ESM remoti e con import dinamici per il caricamento. L’import map dell’host indica "feature-cart": "https://cart-team.example.com/entry.js"; import("feature-cart") carica la versione distribuita più recente.

Senza coordinamento, ogni remoto distribuirebbe la propria copia di React. Gli strumenti di Federation consentono di dichiarare dipendenze condivise: il primo remoto che carica React lo rende disponibile a tutti gli altri. Gli approcci nativi utilizzano import map per indirizzare ogni remoto allo stesso URL di React.

Ogni team è responsabile del proprio remoto e lo distribuisce quando preferisce. L’host non deve mai essere ricostruito: acquisisce le nuove versioni al caricamento successivo della pagina (o tramite l’invalidazione della cache). In questo modo i cicli di rilascio sono completamente disaccoppiati.

Blocchi i remoti su URL versionati (/v1/entry.js, /v2/entry.js) in modo che l’aggiornamento dell’host sia intenzionale anziché implicito. Alcuni team utilizzano la compatibilità semver a livello di import map tramite strumenti come JSPM.

La Federation aggiunge complessità a runtime: più richieste di rete, maggiore difficoltà nel debug tra origini diverse e il rischio di dipendenze condivise incompatibili. La utilizzi quando ha realmente bisogno di una distribuzione indipendente; per i progetti più piccoli, una singola build è più semplice e veloce.

Il crash di un remote non dovrebbe causare l'arresto dell'host. Avvolga le importazioni dinamiche in error boundary (React) o in blocchi try/catch (vanilla) e visualizzi un'interfaccia di fallback quando un remote non funziona. La shell rimane operativa anche se una funzionalità è temporaneamente non disponibile.

Gli export dei remote non dispongono di informazioni sui tipi a compile time nell'host. Generi i tipi TypeScript condivisi in un package separato, utilizzato da entrambi i lati, oppure utilizzi la validazione a runtime (Zod, io-ts) al confine della federazione.

La federazione nativa (import map + ESM) è più semplice e basata sugli standard, ma non dispone del coordinamento delle dipendenze condivise di Webpack. Scelga Webpack/Module Federation per applicazioni complesse con molte dipendenze condivise; scelga la soluzione nativa per configurazioni micro-frontend più semplici.

Il W3C sta esplorando primitive più avanzate per il caricamento dei moduli, che renderebbero la federazione nativa più potente, inclusa una migliore negoziazione delle dipendenze condivise. Oggi consideri le import map come la base e costruisca sopra di esse il tooling per la federazione.

Qual è la motivazione principale per utilizzare Module Federation in un'applicazione di grandi dimensioni?

Module Federation consente a un host di caricare a runtime il codice proveniente da remote distribuiti in modo indipendente. Il tooling di Webpack 5 aggiunge la negoziazione delle dipendenze condivise; la federazione nativa utilizza import map e importazione dinamica. Utilizzarla per architetture micro-frontend con più team, accettando la maggiore complessità in cambio della libertà di distribuire i componenti in modo indipendente.