El lado oscuro de los microfrontends.

Cuando descubrí los microfrontends hace unos años, pensé que había encontrado la solución definitiva a todos mis problemas de arquitectura frontend. Spoiler: no lo era. Y no porque sean una mala tecnología, sino porque, como todo en desarrollo de software, tienen un precio que no siempre se cuenta cuando se habla de implementarlas.

Si estás considerando implementar microfrontends en tu proyecto, o si ya los tienes y te sientes identificado con el caos que voy a describir, este post es para ti.

El sueño prometido

Empecemos por lo bonito. Los microfrontends llegan con una promesa brillante:

• Autonomía total para cada equipo
• Despliegues independientes sin pisar el código de otros
• Escalabilidad organizativa y técnica
• Tecnologías diferentes conviviendo en armonía
• Ownership claro por dominios de negocio

Suena perfecto, ¿verdad? Y en teoría lo es. Cada equipo desarrolla su pedacito del frontend, lo despliega cuando quiere, usa el framework que le apetece y todo funciona como un reloj suizo.

Hasta que no funciona.

Cuando la realidad golpea

La verdad es que la complejidad real de los microfrontends no está en el código, sino en todo lo demás: los equipos, los límites difusos, el mantenimiento, la coordinación.

Déjame contarte lo que nadie te dice cuando te venden esta arquitectura como la bala de plata.

1 Complejidad que no esperabas

"Pasamos de tener un gran monolito difícil de mantener a tener 10 pequeños monolitos difíciles de coordinar."

De repente tienes:

• Multiplicación de pipelines de CI/CD (uno para cada microfrontend).
• Versionado de librerías compartidas que se convierte en una pesadilla.
• Estrategias de comunicación entre microfrontends que nadie documentó bien.
• Sincronización de dependencias que se rompen por todas partes.

Lo que antes era un problema en un solo lugar, ahora son diez problemas distribuidos. Y distribuir problemas no los hace desaparecer, los hace más difíciles de encontrar.

2 La experiencia del usuario se fragmenta

"Cada microfrontend es independiente… hasta que el usuario nota que cada uno tiene un spinner diferente."

Cada equipo tiene sus prioridades, su ritmo, su forma de hacer las cosas. El resultado:

• Inconsistencias visuales por todos lados.
• Performance desigual (uno carga en 200ms, otro en 3 segundos).
• Interacciones que no se sienten coherentes.
• Cambios globales (como hacer un rebranding o mejorar la accesibilidad) que se vuelven misiones casi imposibles.

Al final, el usuario no sabe ni le importa que uses microfrontends. Solo sabe que tu app se siente rara.

3 Integración y seguridad: el dolor de cabeza constante

Compartir autenticación entre microfrontends es más complicado de lo que parece:

• Manejo de tokens entre dominios o contextos.
• Cookies que funcionan en desarrollo pero no en producción.
• Sandboxing cuando usas iframes (y todos los problemas que eso trae).
• Permisos y roles que necesitan estar sincronizados.

Y todo esto mientras intentas mantener las cosas seguras. Diversión garantizada.

4 El coste invisible

Los microfrontends no son gratis. Tienen un coste que no siempre se ve al principio:

• Tiempo de onboarding que se multiplica (ahora hay que entender N arquitecturas).
• Dependencias duplicadas que inflan el bundle.
• Build times más largos porque ahora tienes que construir todo por separado.
• Infraestructura más compleja de mantener y monitorear.

Ah, ¿y tu factura de cloud? También crece.

5 El factor humano (el más importante)

"Los microfrontends no arreglan equipos desalineados; solo hacen los problemas más visibles."

Esto es lo que más me costó aprender: la arquitectura no soluciona problemas organizativos.

Si tus equipos no se comunican, si no hay acuerdos claros, si los límites de responsabilidad son difusos... los microfrontends solo van a amplificar esos problemas:

• Conflictos sobre quién es responsable de qué.
• Trabajo duplicado porque nadie sabe que otro equipo ya lo hizo.
• Falta de coherencia técnica que se convierte en deuda técnica distribuida.

Al final terminamos teniendo equipos de desarrollo enfadados unos con otros.

Entonces, ¿qué hacemos?

No te voy a dejar con mal sabor de boca. Los microfrontends pueden funcionar y, aunque parezca que los odio, ¡nada más lejos de la realidad!. Pero necesitas pensar sobre si realmente los necesitas y estar dispuesto/a a invertir en hacerlo bien.

Aquí van algunas lecciones que he aprendido:

1. Evalúa si realmente los necesitas

Si tu equipo es pequeño o mediano, probablemente no los necesites. Un monolito bien estructurado puede llevarte muy lejos.

2. Establece contratos claros

APIs, eventos, interfaces... todo bien definido y documentado. Sin esto, vas directo/a al caos. Un equipo de Arquitectura bien organizado es tu gran aliado.

3. Comunicación

Tener figuras humanas que sirvan de nexo entre los distintos equipos de desarrollo (dominios de negocio) es indispensable para que todo fluya de forma correcta.

4. Unifica la experiencia

Invierte en un design system sólido y en componentes base compartidos. La consistencia no es negociable.

5. Automatiza todo lo que puedas

Tus pipelines, tus despliegues, tu versionado, tus tests. La complejidad solo es manejable si está automatizada.

6. Organización primero, tecnología después

Los microfrontends deben reflejar cómo trabaja tu organización, no al revés. Recuerda la Ley de Conway: tu arquitectura reflejará inevitablemente la estructura de tu organización.

En conclusión

Como perfiles de arquitectura, no debemos enfocarnos solo en el impacto técnico en el producto final (escalabilidad, resiliencia ante fallos, etc.) sino también en el Developer Experience. Nuestro objetivo debe ser proporcionar las herramientas adecuadas y el apoyo necesario para que los equipos de desarrollo puedan trabajar de manera eficiente y efectiva.

Los microfrontends no son el villano, pero tampoco el héroe que salvará tu proyecto. Son solo una herramienta. Y como toda herramienta poderosa, hay que saber cuándo usarla… y cuándo dejarla en la caja.

La pregunta no es "¿son buenos o malos los microfrontends?", sino "¿resuelven los problemas concretos que tenemos ahora y estamos dispuestos a asumir su coste?"

Si la respuesta es sí, perfecto, úsalos. Si no, no pasa nada: a veces la mejor arquitectura es la más simple que funciona.