Cuándo valen la pena los microfrontends y cuándo no
Los microfrontends rinden bajo condiciones concretas: varios equipos, publicaciones acopladas y áreas de negocio claras. Fuera de esas condiciones solo agregan costo. Así puedes saber de qué lado estás.
Empieza por el problema
Los microfrontends compran una sola cosa: independencia entre equipos. Builds separados, publicaciones separadas, dueños separados. Si nadie está esperando a nadie, no hay nada que comprar.
Por eso el primer paso es buscar evidencia de bloqueos. Revisa los últimos tres meses y cuenta:
- Publicaciones retrasadas porque el trabajo de otro equipo no estaba listo.
- Hotfixes que tuvieron que esperar un ciclo completo de regresión.
- Builds rotos y conflictos de merge causados por cambios sin relación.
- Actualizaciones de framework pospuestas porque los equipos no podían detenerse todos a la vez.
Si la lista es corta, la arquitectura actual está cumpliendo.
Las tres señales
Cantidad de equipos
Uno o dos equipos se coordinan conversando. A partir de unos tres o cuatro equipos que modifican el mismo frontend en cada sprint, la coordinación suele costar más que el trabajo mismo. Es una regla práctica. Hay empresas con cinco equipos en una sola aplicación sin dolor, y otras que sufren con tres.
Acoplamiento de publicaciones
Pregunta cuánto espera un cambio terminado antes de llegar a producción, y por qué. Si la respuesta es "el próximo tren de publicación" o "hasta que QA apruebe toda la app", las publicaciones están acopladas. Es la señal más fuerte, porque es exactamente el problema que los microfrontends eliminan.
Tamaño de la app y límites
El tamaño solo importa junto con límites claros. Una app con 150 pantallas que caen en cinco áreas de negocio con poca superposición se divide bien. Una app donde cada pantalla lee y escribe el mismo registro de cliente, con estado compartido por todas partes, se divide mal sin importar su tamaño.
Tabla de decisión
| Situación | Recomendación |
|---|---|
| Un equipo, cualquier tamaño de app | Aplicación única con límites claros entre módulos |
| Dos equipos, fricción ocasional | Aplicación única en un monorepo, con límites forzados y dueños de código |
| Tres o más equipos, publicaciones acopladas, áreas de negocio claras | Los microfrontends son un candidato razonable |
| Varios equipos, áreas muy entrelazadas | Primero arregla los límites dentro de la app actual y luego reevalúa |
| App legacy grande, varios equipos, migración por delante | Microfrontends entre áreas, migración incremental dentro de cada una |
| Productos separados que deben verse como un solo portal | Microfrontends, normalmente con más aislamiento entre partes |
| Sitio público donde la velocidad de la primera carga es la métrica principal | Prefiere un solo build optimizado; evita la composición en el navegador |
No lo hagas si
- Tienes un solo equipo. No hay de quién independizarse.
- El objetivo es un código más limpio. Los límites se pueden forzar dentro de una sola aplicación con librerías y reglas de lint.
- Nadie será dueño de la plataforma. Sin un dueño con presupuesto para el host, las librerías compartidas y los pipelines, la plataforma se degrada en pocos meses.
- No hay design system ni plan para tenerlo. Cada equipo construirá sus propios botones, y el producto lo mostrará.
- El backend se publica como un solo release para todos. La independencia del frontend ayuda poco si cada funcionalidad sigue esperando una publicación compartida del backend.
- El argumento principal es que otras empresas lo hacen. Su cantidad de equipos y sus problemas son distintos de los tuyos.
La alternativa más barata que conviene probar primero
Una aplicación única y modular resuelve buena parte del dolor por una fracción del costo:
- Una aplicación y un despliegue, dividida en librerías por área de negocio.
- Reglas que impiden que un área importe los internos de otra. Nx lo ofrece con sus reglas de lint de límites entre módulos.
- Lazy loading por área, para que los usuarios descarguen solo lo que abren.
- Dueños de código por carpeta, para que las revisiones lleguen al equipo correcto.
- Un pipeline que construye y prueba solo lo que un cambio afecta.
También es la mejor preparación para los microfrontends. Un área que ya vive en sus propias librerías, con una API pública limpia, es fácil de convertir en un remoto más adelante. El lado del repositorio en esa decisión se discute en Monorepo vs polirepo.
Si decides avanzar, empieza en pequeño
- Elige un área con un dueño claro y pocas dependencias con el resto de la app.
- Construye el host y ese único remoto. Deja todo lo demás en la aplicación actual.
- Resuelve bien el login, las rutas y el design system para este caso.
- Mide la frecuencia de publicación, el tiempo entre merge y producción, y los incidentes de ese equipo.
- Decide sobre la segunda área solo cuando la primera lleve unas semanas en producción.
Un piloto con un remoto cuesta semanas. Un compromiso de toda la plataforma decidido en una diapositiva cuesta trimestres. Deja que el piloto produzca la evidencia.
Qué leer después
Si además estás decidiendo cómo salir de un framework legacy, lee Reescribir, híbrido o microfrontends: cómo elegir. Para una lista más larga de condiciones previas, usa el checklist de preparación para microfrontends.
Más en esta sección
- Module Federation vs Native Federation en Angular
- single-spa vs Module Federation: cómo elegir
- Iframes, web components, paquetes o federation: técnicas de integración comparadas
- El host de microfrontends: de qué es responsable y qué no debe hacer
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn