Micro-frontends en la práctica: ventajas y dificultades

Los micro-frontends llevan a la interfaz la idea de los microservicios: dividir una aplicación web grande en piezas que equipos distintos desarrollan, despliegan y operan por separado. En octubre de 2026 la herramienta principal es Module Federation 2.0, estable desde el 10 de febrero de 2026, mientras que single-spa sigue en la versión 6.0.3 de septiembre de 2024. El patrón compensa cuando cuatro o más equipos se bloquean en la misma aplicación; por debajo de eso, un monorepo da casi lo mismo con menos piezas móviles. Esta guía repasa las opciones actuales, los problemas que aparecen en producción y un criterio para decidir que no. Está disponible en inglés.

Puntos clave

• La señal para plantearse micro-frontends es organizativa: cuatro o más equipos que necesitan publicar a su ritmo y hoy se bloquean en el mismo repositorio o en la misma cadena de despliegue.
• Module Federation 2.0 añade al Module Federation de Webpack 5 un runtime independiente del empaquetador, un manifiesto, tipos remotos y herramientas de depuración; funciona con Webpack, Rspack y Vite.
• single-spa sigue siendo un orquestador válido para mezclar frameworks, pero su última versión estable es de septiembre de 2024 y la 7.0 está en beta desde 2025.
• Los costes que más pesan en producción son las versiones de dependencias compartidas, el CSS que se filtra, el estado compartido y las pruebas de extremo a extremo.
• Si tienes un solo equipo, un producto pequeño o el cuello de botella está en el backend, no los uses: un monorepo con límites de módulo resuelve el problema con menos coste.

¿Cuándo tienen sentido los micro-frontends?

Los micro-frontends tienen sentido cuando el problema es de coordinación entre equipos, no de tecnología. El caso típico son cuatro o cinco equipos de producto que contribuyen a la misma aplicación de página única (SPA) y esperan unos a otros para publicar. El artículo de referencia de Cam Jackson en martinfowler.com^[1] define el objetivo en esos términos: equipos autónomos con despliegues independientes.

Hay tres escenarios en los que el coste se suele recuperar:

• Dominios funcionales separados: un comercio con catálogo, pago y cuenta de usuario, cada uno con su equipo y su ritmo.
• Ciclos de publicación independientes: equipos que necesitan desplegar más de una vez al día sin esperar a la ventana de los demás.
• Migración progresiva: rodear una aplicación heredada con piezas nuevas y retirar la antigua por partes, en lugar de reescribirla de golpe.

¿Qué opciones hay en 2026?

En octubre de 2026 hay cuatro formas de componer micro-frontends, y Module Federation es la que concentra la actividad. Los datos de versión de esta sección los comprobamos en el registro de npm el 27 de octubre de 2026.

iframes

El iframe es la opción con más aislamiento: cada pieza vive en su propio documento y se comunica con postMessage. Ese aislamiento es también su límite, porque la navegación, la accesibilidad, el tamaño del contenido y el posicionamiento en buscadores hay que resolverlos a mano. Sirve para integrar herramientas internas heredadas, no para una experiencia de usuario continua.

Module Federation 2.0

Module Federation nació en Webpack 5, publicado en octubre de 2020, y permite que una aplicación cargue en tiempo de ejecución módulos compilados por otra y comparta dependencias como React. La versión 2.0 se anunció en abril de 2024 y es estable desde el 10 de febrero de 2026. Según su documentación oficial^[2], separa el runtime del empaquetador y añade un manifiesto (mf-manifest.json), tipos para los módulos remotos, plugins de runtime y una extensión de Chrome para depurar.

El cambio práctico es que ya no está atada a Webpack. La misma configuración funciona con Rspack, Rsbuild y Vite (con @module-federation/vite), y hay integraciones para Next.js, Modern.js y Angular. La versión 2.0 estable añadió además la eliminación de código muerto en las dependencias compartidas, que reduce el peso que cada remoto arrastra.

single-spa

single-spa^[3] actúa como enrutador de aplicaciones: monta y desmonta micro-frontends según la URL y permite mezclar React, Vue y Angular en la misma página. Sigue siendo una opción válida para ese caso, pero su ritmo ha bajado. La última versión estable es la 6.0.3, de septiembre de 2024, y la rama 7.0 está en beta (7.0.0-beta.13, de septiembre de 2025).

Native Federation e import maps

Native Federation lleva el modelo de Module Federation a los módulos ES estándar y a los import maps del navegador, sin depender de un empaquetador concreto. Los import maps funcionan en Chrome y Edge desde la versión 89, en Firefox desde la 108 y en Safari desde la 16.4, según los datos de compatibilidad de MDN^[4]. Es la vía que promueve el ecosistema de Angular con @angular-architects/native-federation.

Los problemas que aparecen en producción

Los micro-frontends trasladan complejidad de la organización al tiempo de ejecución, y esa complejidad aparece en seis sitios:

• Versiones de dependencias: si dos equipos cargan versiones incompatibles de React, aparecen fallos que no se reproducen en el equipo de desarrollo. Hace falta una política de versiones compartidas o aceptar paquetes duplicados.
• CSS que se filtra: los estilos globales de una pieza afectan a las demás. CSS Modules, CSS-in-JS o Shadow DOM lo evitan, cada uno con su coste.
• Estado compartido: pasar datos entre piezas sin acoplarlas exige un bus de eventos, eventos personalizados del DOM o un servicio compartido, y ninguno sale gratis.
• Rendimiento: cada pieza trae su propio paquete de JavaScript; sin dependencias compartidas bien configuradas, la página descarga una copia de las mismas bibliotecas por cada pieza.
• Pruebas de extremo a extremo: las pruebas de cada pieza pasan y la composición falla. Hace falta una cadena que pruebe la página completa.
• Coherencia visual: sin un sistema de diseño común, cada equipo deriva y la página parece hecha de retazos.

Module Federation 2.0 ataca parte de estos costes. Su manifiesto y sus plugins de runtime permiten reintentar o sustituir un remoto que no carga, y los ámbitos de compartición múltiples aíslan versiones de una dependencia. Las demás dificultades son de organización y ninguna herramienta las resuelve.

¿Cuándo no usar micro-frontends?

No uses micro-frontends si se cumple cualquiera de estas condiciones, porque el coste de la composición en tiempo de ejecución superará el de coordinar a las personas:

1. Hay un solo equipo de frontend, o dos que se coordinan sin fricción.
2. El producto es pequeño o joven y sus límites de dominio todavía cambian cada pocos meses.
3. El cuello de botella está en el backend, en el diseño o en la cadena de despliegue, no en el código de la interfaz.
4. No hay un sistema de diseño versionado ni un equipo que mantenga la plataforma de composición.
5. Lo que buscas es mezclar frameworks por preferencia, no por una migración con fecha de fin.

Si la respuesta a todas es no, resuelve antes cinco requisitos:

• Un sistema de diseño con componentes publicados como paquetes
• Reglas de versionado aplicadas en la integración continua
• Una cadena que pruebe la página completa
• Observabilidad que correlacione errores por página
• Un equipo de plataforma, la misma figura que describe la guía de platform engineering e IDP

Para la observabilidad, el stack de Grafana con Loki, Tempo y Mimir permite seguir un error a través de las piezas de una misma página.

Alternativas que cuestan menos

Antes del patrón completo hay tres opciones intermedias que dan buena parte del beneficio organizativo:

• Monorepo con límites de módulo: Nx o Turborepo permiten compilaciones y pruebas por proyecto con un único despliegue, y las reglas de dependencias impiden que un equipo importe el código interno de otro.
• Paquetes de componentes: cada equipo publica su parte como biblioteca interna versionada y una sola SPA las consume.
• Fronteras lógicas en el código: contextos delimitados dentro de la misma aplicación, el equivalente en el frontend al monolito modular que compara la guía de módulos frente a microservicios.

Las tres mantienen un solo artefacto desplegable, así que no hay versiones que negociar en tiempo de ejecución. El sistema de diseño compartido sigue siendo necesario, y un sistema de diseño en Figma gestionado como fuente única ayuda en cualquiera de los casos.

Preguntas frecuentes

¿Qué es Module Federation 2.0 y en qué se diferencia del de Webpack 5?

Es la evolución del Module Federation que Webpack 5 incluyó en 2020. Mantiene la carga de módulos remotos y la compartición de dependencias, y añade un runtime independiente del empaquetador, un manifiesto, tipos para los remotos, plugins de runtime y una extensión de Chrome. Funciona con Webpack, Rspack y Vite, y es estable desde el 10 de febrero de 2026.

¿Sigue mantenido single-spa?

Sí, pero con menos actividad que Module Federation. La última versión estable es la 6.0.3, de septiembre de 2024, y la 7.0 está en beta desde 2025. Para orquestar aplicaciones de frameworks distintos por ruta sigue funcionando; para compartir dependencias entre piezas, Module Federation es hoy la opción con más desarrollo.

¿Cuántos equipos hacen falta para que compensen los micro-frontends?

No hay una cifra oficial, pero el patrón empieza a compensar con cuatro o cinco equipos que se bloquean en la misma aplicación y necesitan publicar por separado. Con uno o dos equipos, un monorepo con límites de módulo da casi todo el beneficio sin la complejidad de componer la página en tiempo de ejecución.

Conclusión

Los micro-frontends son una herramienta legítima para organizaciones grandes con un problema real de coordinación en el frontend, y en 2026 Module Federation 2.0 es su base más activa. No son una mejora de arquitectura por sí mismos: trasladan complejidad de la organización al tiempo de ejecución. Compensan solo cuando el coste de coordinar a las personas supera al de esa complejidad añadida; en cualquier otro caso, empieza por un monorepo bien delimitado.

Fuentes: [1] Cam Jackson, Micro Frontends, en martinfowler.com^[1], [2] Module Federation, documentación oficial^[2], [3] Module Federation 2.0 Stable Release^[5], [4] single-spa, guía de inicio^[3], [5] Import maps en MDN^[4].

Fuentes

1. martinfowler.com
2. documentación oficial
3. single-spa
4. datos de compatibilidad de MDN
5. Module Federation 2.0 Stable Release