Microfrontends de React con Webpack Module Federation
Sustituya las soluciones alternativas con iframe por Webpack 5 Module Federation para que las aplicaciones React locales y remotas compartan un entorno de ejecución, se desplieguen de forma independiente y, aun así, parezcan un único producto.
Las grandes superficies de los productos rara vez son un único frontend. Los procesos de pago, las pantallas de control, los ajustes y el elemento decorativo que los rodea suelen pertenecer a equipos diferentes, cada uno con su propio backlog, deudas técnicas y calendario de lanzamientos. Esa estructura se denomina habitualmente micro-frontends: fragmentos de interfaz de usuario gestionados de forma independiente que, aun así, se presentan como un único producto, siendo el análogo en el lado del cliente de los microservicios.
Durante mucho tiempo, las herramientas de React para este patrón resultaron poco prácticas. Las organizaciones o bien mantenían un único paquete gigante de SPA o bien integraban aplicaciones separadas en iframes, aceptando las consecuencias. La Module Federation de Webpack 5 hizo posible una tercera opción: aplicaciones JavaScript desarrolladas e implementadas de forma independiente que se componen en tiempo de ejecución dentro de un mismo documento del navegador. Comprender qué hace esta función y por qué reemplazó a los métodos anteriores es importante para quienes diseñan sistemas React con múltiples equipos.
El problema antes de la Module Federation
Antes de que Federation se lanzara, los equipos que querían una entrega independiente del frontend tenían pocas opciones.
La opción por defecto era el SPA monolítico: un repositorio, un pipeline y un despliegue. Ese modelo funciona bien para un grupo pequeño. A medida que la responsabilidad se distribuye, aumentan las fricciones. Cada funcionalidad comparte la misma compilación. Los tiempos de compilación aumentan con el tamaño del código. Una regresión en un área puede bloquear el proceso de lanzamiento de otro equipo. Alinear los despliegues entre muchos grupos se convierte en una tarea de gestión de proyectos por sí misma.
Los iframes eran otra solución común. Incrustar una aplicación hija completa dentro de una página padre permitía una verdadera independencia en los despliegues, y por eso muchas empresas las utilizaban. Sin embargo, rápidamente surgieron muchos inconvenientes:
- El aislamiento es absoluto. Los estilos, el DOM y los contextos de JavaScript no se mezclan. Compartir estado, coordinar datos o imponer un mismo lenguaje de diseño entre elementos padre e hijo se convierte en una tarea técnica compleja en lugar de un simple paso de propiedades.
- Las dependencias se duplican. Cada frame suele cargar su propio React, bibliotecas compartidas y CSS. Los usuarios descargan los mismos datos una y otra vez.
- La experiencia de usuario se ve afectada. El desplazamiento, el enfoque, el cambio de tamaño, los enlaces profundos y la historia entre los frames requieren soluciones personalizadas y siguen resultando incompletos.
- El SEO y la accesibilidad se ven perjudicados. El contenido dentro de los frames es más difícil de indexar y menos consistente para las tecnologías de asistencia.
- La comunicación se limita a mensajes. La transferencia de datos entre frames implica el uso de
postMessagey protocolos manuales; no existe memoria compartida ni contexto de React compartido.
Los iframes resolvieron el problema de enviar de forma independiente, pero crearon uno peor relacionado con integrarse de manera limpia. Lo que faltaba era la independencia en el momento de compilación e implementación sin sacrificar una experiencia de usuario basada en un único documento.
¿Qué es Module Federation?
Module Federation, introducido con Webpack 5, permite que aplicaciones JavaScript desarrolladas e implementadas por separado compartan código en tiempo de ejecución en lugar de en tiempo de compilación.
En la práctica, se pueden ejecutar varias aplicaciones —de diferentes equipos, procesos y versiones— que aún así se integran en el navegador como un único producto. Una aplicación expone un componente, una ruta o una función auxiliar; otra la consume como si estuviera en el mismo paquete, sin tener que volver a compilarla cuando cambia la aplicación proveedora.
Esa composición en tiempo de ejecución es la base técnica habitual para los microfrontends con React hoy en día.
Cómo funciona: hosts, remotos y dependencias compartidas
La federación define dos roles:
- host carga código publicado en otro lugar. Suele ser la capa que monta la interfaz de usuario de otros equipos.
- remoto publica módulos para otros: páginas, componentes, hooks o utilidades.
Una aplicación puede ser ambos: exponer algunos módulos mientras consume otros.
Los remotos declaran las exportaciones en la configuración de Webpack; los hosts declaran qué remotos cargar y qué símbolos importar. La carga se realiza en el navegador desde una URL de entrada remota. La compilación del host no necesita el código fuente del remoto, solo un punto de entrada estable que pueda obtener cuando se ejecuta la aplicación.
Dependencias compartidas completan la imagen. Cuando tanto el host como el remoto necesitan React, se puede indicar a Federation que comparta una única instancia de React en lugar de enviar dos. Esto elimina la duplicación al estilo iframe mientras sigue permitiendo a los equipos utilizar versiones diferentes cuando es necesario.
Module Federation vs. Iframes
Esa comparación explica por qué tantos equipos abandonaron los iframes una vez que Federation maduró. Se mantiene la independencia en el despliegue que hacía atractivos los iframes, sin sacrificar la calidad de integración. Los componentes remotos se integran en el DOM del host, comparten un mismo entorno de JavaScript y pueden reutilizar proveedores, estado y paquetes del sistema de diseño; tareas que antes eran difíciles o imposibles al trascender los límites de un iframe.
Por qué lo usan los equipos grandes
Los productos pequeños rara vez necesitan esta infraestructura. Las organizaciones con numerosos equipos front-end utilizan Federation para resolver cuellos de botella estructurales:
- Despliegues independientes. Un equipo remoto puede enviar una corrección sin tener que volver a generar los artefactos de todos los demás equipos.
- Autonomía del equipo. Cada grupo mantiene su propio ritmo, sistema de integración continua y, dentro de ciertos límites, sus propias opciones de herramientas.
- Construcciones más rápidas. Al tener equipos remotos separados, un pequeño cambio no obliga a reconstruir todo el sistema de forma integral.
- Modernización incremental. Los entornos heredados pueden ir incorporando nuevos equipos remotos poco a poco, en lugar de realizar un cambio completo de una sola vez.
- Flexibilidad en la tecnología utilizada. Compartir un mismo framework es lo más sencillo, pero a veces los equipos conectan versiones diferentes —o, con mayor esfuerzo, frameworks distintos— a través de las fronteras establecidas por la Federación.
Casos de uso en el mundo real
Los sitios de comercio electrónico suelen permitir que los equipos encargados del catálogo, la compra y las cuentas tengan control remoto independiente. Los productos SaaS proporcionan widgets de panel de control o paneles de configuración desarrollados por los equipos de funcionalidades, sin necesidad de modificar la estructura principal cada vez que se realiza un cambio. Las migraciones permiten separar partes de una SPA heredada en módulos remotos mientras la interfaz antigua sigue funcionando.
Resumen de los beneficios clave
Los principales beneficios de la federación son pocos: una capacidad real de despliegue independiente, un entorno de ejecución compartido que evita la duplicación de bibliotecas y mensajes frágiles entre aplicaciones, y una experiencia de usuario que sigue pareciendo la de una sola aplicación. Ofrece la autonomía prometida por los marcos iframes sin las complicaciones ni las consecuencias negativas en términos de integración y rendimiento.
Conclusión
Pasar de los iframes a Module Federation forma parte de una mayor madurez en la arquitectura del frontend: la independencia en el despliegue y una experiencia de usuario coherente ya no tienen por qué ser opuestos. Webpack 5 hizo posible esta combinación para organizaciones que utilizan mucho React y que ya no podían seguir dependiendo de un único paquete. A medida que aumenta la adopción y herramientas como Rspack y Module Federation 2.0 amplían las mismas ideas de compartir entornos de ejecución, entender por qué ocurrió este cambio ayuda a quienes diseñan sistemas grandes basados en React a definir deliberadamente los límites de responsabilidad, en lugar de recurrir por defecto a iframes o a un monolito que sigue creciendo.
Pruébalo tú mismo
Existe un ejemplo mínimo de host/remoto disponible en react_module_federation.
Clónalo localmente:
git clone https://github.com/ModithaM/react_module_federation.git
cd react_module_federation
Primero inicia el remoto para que su punto de entrada esté listo antes de que el host solicite los módulos:
cd remote
npm install
npm start
En otra terminal, inicia el host:
cd host
npm install
npm start
Abra el host en el navegador; debería cargar los componentes remotos en tiempo de ejecución y demostrar la relación descrita anteriormente. El orden es importante: un host iniciado por sí solo no tiene nada que descargar hasta que el remoto esté listo, lo cual sirve como recordatorio útil de que la independencia de Federation sigue dependiendo de que los remotos sean accesibles al arrancar la shell.
Lecturas relacionadas
- Frentends de JavaScript autoadaptativos para interfaces gestionadas por IA — Cómo la transmisión en flujo, la recuperación de vectores, el estado reactivo, los componentes dinámicos y la observabilidad transforman la arquitectura del cliente para interfaces UI nativas de IA.