Module Federation vs Native Federation en Angular

Los dos cargan en tiempo de ejecución código Angular desplegado por separado y comparten dependencias entre host y remotos. La diferencia está en quién hace la carga: el runtime de un bundler o el propio navegador.

La misma idea, dos implementaciones

Federation permite que una aplicación host cargue código de aplicaciones construidas y desplegadas por separado, llamadas remotos, mientras la página está corriendo. También les permite compartir dependencias, como el propio Angular, para que el framework se descargue y se instancie una sola vez.

Webpack Module Federation y Native Federation hacen ambas cosas. Comparten el vocabulario (host, remoto, módulo expuesto, dependencia compartida). Se diferencian en el mecanismo que hay debajo.

Cómo carga los remotos Webpack Module Federation

Module Federation es una funcionalidad de Webpack 5 que se configura con ModuleFederationPlugin. El build de cada remoto produce un archivo pequeño, normalmente llamado remoteEntry.js. Ese archivo describe qué módulos expone el remoto y qué librerías compartidas necesita.

En tiempo de ejecución, el host carga ese archivo. El runtime de Webpack, que va incluido en cada aplicación, negocia las versiones de las dependencias compartidas y luego descarga los chunks del módulo pedido.

En Angular, la integración habitual es @angular-architects/module-federation, que agrega el plugin al build del Angular CLI mediante una configuración personalizada de Webpack. Rspack, un bundler compatible con Webpack, también soporta Module Federation.

Cómo carga los remotos Native Federation

Native Federation (@angular-architects/native-federation) mantiene el mismo modelo mental y lo construye sobre estándares del navegador. Los remotos se construyen como ES modules. Las dependencias compartidas se construyen como bundles ES module separados. Cada remoto publica un archivo de metadatos, remoteEntry.json.

Al iniciar, el host lee esos metadatos y crea un import map. Un import map le dice al navegador qué URL usar para cada nombre de paquete. Después de eso, cargar un remoto es un import() dinámico estándar.

Una configuración típica tiene un manifiesto que lista los remotos:

{
  "billing": "https://billing.example.com/remoteEntry.json",
  "catalog": "https://catalog.example.com/remoteEntry.json"
}

Y una ruta del host que carga un módulo expuesto:

{
  path: 'billing',
  loadChildren: () =>
    loadRemoteModule('billing', './routes')
      .then(m => m.BILLING_ROUTES)
}

Como el mecanismo no depende del runtime de un bundler, funciona con el application builder de Angular basado en esbuild, que es el builder por defecto en proyectos nuevos desde Angular 17. Muchas configuraciones incluyen el polyfill es-module-shims para cubrir vacíos en el manejo de import maps de los navegadores.

Implicaciones para las herramientas de build

Aquí importa la dirección del Angular CLI. El sistema de build más nuevo se basa en esbuild y Vite, y las funcionalidades nuevas de build llegan ahí. El builder basado en Webpack sigue funcionando, pero quedarse en él significa quedarse en el camino antiguo. Los builds con esbuild además suelen ser mucho más rápidos, algo que todos los equipos notan en el desarrollo local y en CI.

Cuándo elegir cada uno

Elige Webpack Module Federation cuando:

• Ya tienes una plataforma funcionando sobre él. Una configuración estable vale más que un mecanismo más nuevo.
• Tus aplicaciones usan versiones antiguas de Angular, anteriores al builder basado en esbuild.
• Tus builds dependen de loaders o plugins específicos de Webpack.
• Tienes que integrar remotos de otros equipos que ya publican contenedores de Module Federation.

Elige Native Federation cuando:

• Vas a empezar una plataforma nueva sobre una versión actual de Angular.
• Quieres quedarte en el builder por defecto del Angular CLI y sus builds más rápidos.
• Prefieres un mecanismo basado en estándares a uno atado a un bundler.

Pasar de uno a otro

Los conceptos se corresponden uno a uno, así que la migración es sobre todo trabajo de configuración: el archivo de federation, el código de arranque de cada aplicación y las llamadas que cargan remotos. Planifica tres cosas:

1. Orden. Por defecto, los dos runtimes no comparten dependencias entre sí. Mezclarlos en una misma página es posible con trabajo adicional de puente. Trátalo como un estado de transición con fecha de fin.
2. Compatibilidad de librerías. Verifica que todas las librerías compartidas estén disponibles como ES modules antes de comprometerte.
3. Pipelines. Los archivos que el host descubre cambian de remoteEntry.js a remoteEntry.json. Las reglas de despliegue y de caché necesitan el mismo ajuste. Mira CI/CD para microfrontends.

Las reglas de versiones están en Dependencias compartidas y versiones. Si también estás evaluando un orquestador, lee single-spa vs Module Federation.

Más en esta sección

• single-spa vs Module Federation: cómo elegir
• Iframes, web components, paquetes o federation: técnicas de integración comparadas
• El host de microfrontends: de qué es responsable y qué no debe hacer
• Rutas entre microfrontends: dueños de rutas, deep links y contrato de navegación