Qué es Module Federation: integrar en runtime

Todo lo que has visto en este track asumía una frontera sagrada: el grafo de módulos se cierra durante el build. El bundler resuelve cada import, agrupa todo en chunks y sella el resultado; lo que no estaba presente al compilar, sencillamente no existe para esa aplicación. Module Federation rompe esa frontera. Permite que una aplicación cargue, en tiempo de ejecución, código de otra aplicación distinta —compilada, versionada y desplegada por su cuenta— como si fuera un módulo propio. El grafo deja de ser un archipiélago cerrado y pasa a ser una red que cruza fronteras de despliegue.

La frontera que un bundle no cruzaba

Durante todo este track, integrar código ajeno significó una cosa: instalarlo como dependencia y dejar que el bundler lo absorbiera. Cuando escribes import de una librería, esa librería entra en tu grafo, se resuelve, se poda por tree-shaking y termina fundida en tus chunks. La integración ocurre en el build, y el artefacto que despliegas es autosuficiente: contiene todo lo que necesita, congelado en el instante en que compilaste.

Esa autosuficiencia tiene un precio que rara vez se nombra: para cambiar cualquier trozo de código, hay que reconstruir y redeplegar la aplicación entera. Si diez aplicaciones comparten un botón y el botón cambia, las diez se recompilan. El grafo cerrado es cómodo, pero acopla el ciclo de vida de todo lo que vive dentro de él.

Module Federation introduce una segunda vía: la integración en runtime. En lugar de fundir el código ajeno en tu build, tu aplicación lo va a buscar cuando lo necesita, mientras el usuario navega. El código remoto vive en otro servidor, se construyó con otro pipeline y se desplegó en otro momento. Para tu aplicación es un import más; por debajo, es una petición de red a un artefacto que nunca formó parte de tu compilación.

// Parece un import local, pero "remoteUI" vive en OTRO despliegue.
// El navegador lo resuelve en runtime, no el bundler en build.
const { Boton } = await import("remoteUI/Boton");

La palabra clave es cuándo. Un paquete npm se integra al compilar; un remote federado se integra al ejecutar. Ese desplazamiento en el tiempo es toda la idea, y de él se derivan tanto los poderes como los peligros que veremos en el resto del nivel.

El contenedor y su manifiesto

Para que una aplicación exponga código a otras, no basta con desplegarla: tiene que publicar un contenedor federado. El contenedor es un pequeño punto de entrada —clásicamente un archivo remoteEntry.js, y en la runtime 2.0 un manifiesto mf-manifest.json— que describe qué módulos ofrece y cómo cargarlos. Es el índice público del remote: quien lo lea sabe qué puede pedir y dónde están los chunks reales.

El protocolo por debajo es deliberadamente simple. El contenedor expone dos operaciones: una para inicializarse compartiendo el ámbito de dependencias comunes, y otra para pedir un módulo concreto, que devuelve una fábrica perezosa.

// El protocolo del contenedor, simplificado y a mano.
await __webpack_init_sharing__("default");
const container = window.remoteUI;                 // vino de remoteEntry.js
await container.init(__webpack_share_scopes__.default);
const factory = await container.get("./Boton");    // pide un modulo expuesto
const Modulo = factory();                            // lo evalua bajo demanda

Nadie escribe esto a mano. El bundler reescribe tus import("remoteUI/Boton") en esta danza de init y get, y la runtime moderna la envuelve en una sola llamada legible. Pero conviene haber visto el mecanismo desnudo una vez: te recuerda que un remote no es magia, sino un archivo índice y un puñado de chunks servidos por HTTP.

import { init, loadRemote } from "@module-federation/runtime";

init({
  name: "host",
  remotes: [
    { name: "remoteUI", entry: "https://cdn.example.com/remoteUI/mf-manifest.json" },
  ],
});

const { default: Boton } = await loadRemote("remoteUI/Boton");

flowchart LR
subgraph Build tradicional
  S[tu codigo] --> B[bundler]
  L[librerias] --> B
  B --> G[un grafo cerrado y sellado]
end
subgraph Runtime con federacion
  H[host] -->|carga en runtime| M[manifiesto del remote]
  M --> C[chunks del remote desplegados aparte]
end
style G fill:#a6e3a1,color:#11111b
style H fill:#cba6f7,color:#11111b
style M fill:#f9e2af,color:#11111b
style C fill:#89b4fa,color:#11111b

No es un paquete npm

La reacción natural es preguntarse en qué se diferencia esto de publicar un paquete. La respuesta está, otra vez, en el cuándo. Un paquete npm compartido obliga a un ritual: publicas una versión nueva, y cada aplicación que lo consume debe actualizar su package.json, reinstalar, recompilar y redeplegar para incorporar el cambio. El código nuevo viaja por el ciclo de build de cada consumidor. Con diez consumidores, son diez pipelines que hay que orquestar para propagar un arreglo.

Un remote federado invierte ese flujo. Publicas el remote una sola vez en su URL, y los consumidores recogen la versión nueva en su siguiente carga, sin recompilar nada. El código nuevo no viaja por el build de nadie: viaja por la red, en el instante en que el usuario lo pide.

Esa última fila anticipa el precio: al mover la integración a runtime, mueves también los fallos a runtime. Un paquete roto se detecta al compilar; un remote roto se detecta cuando el usuario ya está en la página. Todo el poder de la federación —desplegar de forma independiente— viene con esa contrapartida, que estudiaremos a fondo en la última lección del nivel.