En pocas palabras
Permite componer módulos publicados por aplicaciones independientes y compartir dependencias en ejecución.
Qué problema resuelve
Acoplamiento de releases entre equipos que mantienen partes de una aplicación grande.
Cuándo utilizarlo
Microfrontends con autonomía real. Ejemplo: integrar un módulo de facturación en un shell común.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
En el Radar compartido: Trial (valoración de la edición aportada).
Cómo funciona
Un host descubre y carga módulos remotos; la configuración define exposiciones y dependencias compartidas. El ecosistema ofrece runtimes y plugins para varios bundlers.
Ejemplo de uso
Publicar un remoto con una pantalla y cargarlo desde el portal. Probar versiones compatibles y mostrar un fallback si el remoto falla o no está disponible.
Configuración de un remoto y un host
// rsbuild.config.ts / webpack.config.js del remoto "facturacion"
new ModuleFederationPlugin({
name: 'facturacion',
exposes: { './Facturas': './src/Facturas.tsx' },
shared: {
react: { singleton: true, requiredVersion: '^19.0.0' },
'react-dom': { singleton: true, requiredVersion: '^19.0.0' },
},
});
// host "portal"
new ModuleFederationPlugin({
name: 'portal',
remotes: {
facturacion:
'facturacion@https://cdn.krediya.example/facturacion/mf-manifest.json',
},
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
});
const Facturas = React.lazy(() => import('facturacion/Facturas'));
<ErrorBoundary fallback={<AvisoModuloNoDisponible />}>
<Suspense fallback={<Cargando />}>
<Facturas clienteId={id} />
</Suspense>
</ErrorBoundary>;
singleton: true evita cargar dos copias de React, lo que rompería hooks y contexto.
Module Federation 2.0
| Capacidad | Beneficio |
|---|---|
Manifest (mf-manifest.json) |
Describe exposiciones y dependencias; facilita herramientas y precarga |
| Runtime API | registerRemotes y loadRemote para decidir remotos en ejecución (por entorno, por usuario) |
| Tipos | Generación y descarga automática de tipos TypeScript de los remotos |
| Multi-bundler | webpack, Rspack, Rsbuild, Vite y frameworks como Modern.js |
| DevTools | Extensión de navegador para apuntar un remoto a una versión local |
Alternativas para micro-frontends
| Opción | Composición | Rasgos |
|---|---|---|
| Paquetes npm | En build | Simple; cada cambio exige redeploy del host |
| Module Federation | En runtime | Despliegue independiente y dependencias compartidas |
| Import maps + ESM | En runtime | Estándar del navegador, menos gestión de dependencias |
| single-spa | En runtime | Orquesta varios frameworks en una página |
| iframes | En runtime | Aislamiento total, integración y UX limitadas |
| Composición en servidor | En servidor/edge | Fragmentos HTML; buen rendimiento inicial |
Cuándo compensa
Module Federation resuelve un problema organizativo: varios equipos que necesitan desplegar partes de una misma interfaz sin coordinarse en cada release. Si un solo equipo mantiene la aplicación, un monorepo con Turborepo y paquetes compartidos suele ser más simple y rápido.
Riesgos
- Incompatibilidades de versiones compartidas en ejecución: define una política de versiones de React y del sistema de diseño.
- Rendimiento: muchas peticiones y código duplicado si
sharedno está bien configurado. - Estilos que se pisan entre remotos: usa CSS modules, prefijos o Shadow DOM.
- Contratos implícitos (props, eventos, rutas): documéntalos y pruébalos como cualquier API.
Criterios de implementación
Coordinar routing, autenticación, estilos y versiones de dependencias. Evaluar SSR y rendimiento con las integraciones elegidas y evitar federar sin una necesidad organizativa clara.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.