Los micro-frontends llevan a la UI la idea de los microservicios: dividir una aplicación grande en piezas que distintos equipos pueden desarrollar, desplegar y operar de forma independiente. La promesa es atractiva — equipos pequeños y autónomos sin pisarse en un monolito React de medio millón de líneas — pero en 2023, después de varios años de adopción real, ya tenemos suficientes cicatrices como para hablar con honestidad.
Cuándo tiene sentido (y cuándo no)
La señal más clara para considerar micro-frontends es organizativa, no técnica. Si tienes un único equipo trabajando en el frontend, no los necesitas. Cuatro o cinco equipos contribuyendo al mismo SPA y bloqueándose mutuamente en la pipeline es donde la conversación empieza a tener sentido.
Casos donde suele compensar:
- Aplicaciones grandes con dominios funcionales claramente separados (catálogo, checkout, cuenta de usuario).
- Empresas con varios equipos de producto que necesitan ciclos de release independientes.
- Migraciones progresivas — rodear un legacy con piezas modernas sin reescribir todo.
Casos donde es prematuro:
- Startups y productos pequeños donde la coordinación se hace en una conversación de Slack.
- Equipos que aún no han establecido convenciones internas estables (vas a multiplicar el desorden).
- Cuando el cuello de botella real es el backend o el diseño, no el desarrollo frontend.
Los patrones principales
Tres aproximaciones dominan en 2023:
Iframes (sí, todavía)
La opción más simple y aislada. Cada micro-frontend vive en un iframe; comunicación vía postMessage. Funciona, pero tiene problemas conocidos: SEO, navegación, accesibilidad, y la sensación de “app dentro de app”. Útil para integrar terceros o herramientas internas legacy. Mal candidato para experiencias de usuario fluidas.
Module Federation (Webpack 5)
Webpack 5 introdujo Module Federation, que permite a una aplicación cargar dinámicamente módulos compilados de otra app en runtime. Es la opción más popular para proyectos React/Vue serios desde 2022. Permite compartir dependencias (un único React entre apps) y mantiene la sensación de SPA unificada.
El coste: configuración de Webpack compleja, gestión cuidadosa de versiones de dependencias compartidas, y debugging que requiere paciencia. La incompatibilidad de versiones es la fuente número uno de incidentes.
Single-SPA y orquestadores
Single-SPA actúa como router de aplicaciones, montando y desmontando micro-frontends en respuesta a la URL. Bueno para mezclar frameworks (React + Vue + Angular en la misma página), aunque ese caso de uso es más raro de lo que parece — la mayoría termina estandarizando un único framework.
Las trampas que nadie cuenta en las charlas
Después de varios proyectos en producción, los problemas reales que más cuestan:
- CSS leakage. Estilos globales de un micro-frontend “se escapan” a otros. Soluciones: CSS-in-JS, CSS Modules, Shadow DOM. Todas tienen su precio.
- Versiones de dependencias. Tres equipos en tres versiones de React = corrupción del estado, bugs imposibles de reproducir. Necesitas governance estricta o aceptar el coste de bundle duplicado.
- Estado compartido. Pasar datos entre micro-frontends sin acoplarlos es difícil. Event bus, custom events, o servicios compartidos — ninguno es elegante.
- Performance. Cada micro-frontend trae su propio bundle. Sin shared dependencies bien configuradas, el peso total puede multiplicarse por 3-4.
- Testing end-to-end. Probar la integración completa requiere infraestructura adicional. Los tests por micro-frontend pasan; el conjunto se rompe.
- Diseño visual. Sin un design system maduro, cada equipo deriva. La página parece cosida con retazos.
Prerrequisitos no negociables
Si decides avanzar, estos elementos deben existir antes:
- Design system robusto con componentes versionados (idealmente como paquetes npm publicados).
- Convenciones de versionado claras y enforced para dependencias compartidas.
- Pipeline de integración que pruebe la composición completa, no solo cada pieza.
- Observabilidad unificada — errores y métricas tienen que correlacionarse a nivel de página, no de micro-frontend.
- Equipo de plataforma dedicado que mantenga el orquestador y resuelva problemas transversales.
Sin esto, los micro-frontends multiplican problemas en lugar de resolverlos.
Alternativas más baratas
Antes de saltar al patrón completo, valora opciones intermedias:
- Monorepo bien estructurado (Nx, Turborepo) con builds independientes pero deploy unificado.
- Component packages publicados como librerías internas, consumidas por una sola SPA.
- Bounded contexts en el código sin separar el deploy — fronteras lógicas, no físicas.
Estas opciones dan mucho del beneficio organizativo sin los costes operativos.
Conclusión
Los micro-frontends son una herramienta legítima para organizaciones grandes con problemas reales de coordinación frontend. No son una mejora arquitectónica per se — son una transferencia de complejidad de la organización al runtime. Esa transferencia compensa solo cuando los costes de coordinación humana superan los costes técnicos añadidos.
Si tu primera pregunta al leer esto fue “esto suena complicado”, probablemente no los necesitas. Síguenos en jacar.es para más sobre arquitectura frontend pragmática.
