Conceptos básicos de Module Federation

Module Federation permite que una aplicación JavaScript cargue y ejecute código de otra aplicación desplegada de forma independiente durante la ejecución. El patrón se originó en Webpack 5 y ahora también es posible mediante mapas de importaciones nativos e importación dinámica.

Las organizaciones grandes dividen los monolitos en varios "micro-frontends" desplegados de forma independiente: un host principal y varias aplicaciones de funcionalidades. Module Federation permite que el host cargue cada funcionalidad bajo demanda sin empaquetarlas juntas durante la compilación.

En Webpack 5, el host declara remotes (otras aplicaciones que va a consumir) y los remotos declaran exposes (lo que ofrecen). El entorno de ejecución obtiene un manifiesto pequeño de cada remoto al iniciarse y descarga los fragmentos cuando el host los importa.

Sin Webpack, la misma idea funciona con mapas de importaciones que apuntan a bundles ESM remotos y con importación dinámica para cargarlos. El mapa de importaciones del host indica "feature-cart": "https://cart-team.example.com/entry.js"; import("feature-cart") carga la versión desplegada más reciente.

Sin coordinación, cada remoto enviaría su propia copia de React. Las herramientas de federación permiten declarar dependencias compartidas: el primer remoto que carga React lo pone a disposición de todos los demás. Los enfoques nativos utilizan mapas de importaciones para apuntar todos los remotos a la misma URL de React.

Cada equipo es responsable de su remoto y lo despliega cuando quiere. El host nunca se vuelve a compilar; incorpora las nuevas versiones en la siguiente carga de página (o mediante invalidación de caché). Esto desacopla por completo los ciclos de lanzamiento.

Fije los remotos a URL versionadas (/v1/entry.js, /v2/entry.js) para que la actualización del host sea intencionada y no implícita. Algunos equipos utilizan la compatibilidad con semver en el nivel del mapa de importaciones mediante herramientas como JSPM.

La federación añade complejidad en tiempo de ejecución: más solicitudes de red, depuración más difícil entre orígenes y riesgo de incompatibilidad entre dependencias compartidas. Utilícela cuando realmente necesite despliegues independientes; en proyectos pequeños, una única compilación es más sencilla y rápida.

El bloqueo de un remoto no debería hacer caer al host. Envuelva las importaciones dinámicas en límites de error (React) o en bloques try/catch (JavaScript puro), y muestre una interfaz alternativa cuando falle un remoto. El shell seguirá funcionando aunque una funcionalidad esté temporalmente averiada.

Las exportaciones remotas no tienen información de tipos en tiempo de compilación dentro del host. Genere tipos compartidos de TypeScript en un paquete independiente que consuman ambos lados, o use validación en tiempo de ejecución (Zod, io-ts) en el límite de federación.

La federación nativa (mapas de importación + ESM) es más sencilla y se basa en estándares, pero carece de la coordinación de dependencias compartidas de Webpack. Elija Webpack/Module Federation para aplicaciones complejas con muchas dependencias compartidas; elija la opción nativa para configuraciones de microfrontends más sencillas.

El W3C está explorando primitivas más completas para la carga de módulos que harían más capaz a la federación nativa, incluida una mejor negociación de dependencias compartidas. Actualmente, considere los mapas de importación como la base y añada sus herramientas de federación sobre ellos.

¿Cuál es la principal motivación para usar Module Federation en una aplicación grande?

Module Federation permite que un host cargue código de remotos desplegados de forma independiente durante la ejecución. Las herramientas de Webpack 5 añaden negociación de dependencias compartidas; la federación nativa usa mapas de importación e importaciones dinámicas. Úselo en arquitecturas de microfrontends con varios equipos y acepte la complejidad adicional a cambio de la libertad de desplegar de forma independiente.