Errores comunes en microfrontends y cómo evitarlos

Un grupo pequeño de errores de diseño y de organización aparece una y otra vez en las plataformas de microfrontends. Cada uno es fácil de reconocer y tiene una solución conocida.

1. Dividir demasiado

Cómo se ve: un remoto para el encabezado, uno para un buscador, uno por cada widget. Una sola pantalla compone cinco o seis remotos.

Por qué duele: cada remoto tiene un costo fijo en pipeline, monitoreo, versiones y tiempo de carga. Los remotos pequeños pagan ese costo muchas veces y no ganan nada, porque normalmente un mismo equipo es dueño de varios y los cambia juntos.

Cómo evitarlo: divide por área de negocio con un equipo detrás. Un remoto debe ser lo bastante grande para entregar funcionalidades completas por sí solo. Si tienes más remotos que equipos, fusiona algunos.

2. Estado mutable compartido

Cómo se ve: un store global que todos los remotos leen y escriben, u objetos en window que varias áreas modifican.

Por qué duele: el estado se vuelve una interfaz oculta. Un cambio en su forma rompe otros remotos en ejecución, sin un compilador que avise. El orden de las publicaciones empieza a importar.

Cómo evitarlo: cada remoto es dueño de su estado. Comparte solo un contexto pequeño y de solo lectura desde el host: usuario, permisos, idioma. Para todo lo demás usa navegación con parámetros, unos pocos eventos versionados y el backend como fuente de verdad. Mira comunicación entre microfrontends.

3. Publicaciones acopladas

Cómo se ve: un calendario de publicaciones del frontend, un ambiente de staging compartido que debe estar en verde para todos, cambios que solo funcionan si dos remotos se despliegan el mismo día.

Por qué duele: el despliegue independiente es la razón de ser de la arquitectura. Sin él, pagaste una plataforma y te quedaste con el proceso del monolito.

Cómo evitarlo: haz que cada cambio sea compatible con lo que está en producción. Agrega antes de quitar: publica el campo o el evento nuevo, migra a los consumidores y después borra el viejo. Prueba cada versión nueva contra las versiones de producción de los demás.

4. Sin design system

Cómo se ve: cada equipo da estilo a sus propios botones, tablas y formularios. Los espaciados y el comportamiento cambian entre áreas. Los usuarios notan dónde termina el trabajo de un equipo.

Por qué duele: el producto pierde coherencia, los arreglos de accesibilidad hay que repetirlos en cada remoto, y todos los equipos gastan tiempo en los mismos componentes básicos.

Cómo evitarlo: empieza un design system compartido antes del segundo remoto, aunque sea pequeño: tokens, tipografía y los componentes más usados. Dale un dueño y una política de versionado. Mira design system entre microfrontends.

5. Sin dueños

Cómo se ve: remotos que todos cambian, un host que se mantiene en los ratos libres, alertas que llegan a un canal general. Cuando algo se rompe, la primera hora se va en encontrar a quién le toca mirar.

Por qué duele: el código sin dueño se deteriora. El host en particular acumula arreglos rápidos de todos los equipos hasta que nadie se atreve a cambiarlo.

Cómo evitarlo: un equipo dueño por remoto, anotado junto a la tabla de rutas. Un equipo de plataforma, o al menos personas con nombre y tiempo asignado, para el host, las plantillas de pipeline y el contrato. Más en equipos y ley de Conway.

6. Deriva de versiones

Cómo se ve: remotos en tres versiones distintas del framework y cuatro del design system. Las actualizaciones se postergan porque las funcionalidades van primero.

Por qué duele: los singletons compartidos dejan de funcionar entre versiones incompatibles. El runtime entonces carga duplicados, lo que cuesta rendimiento, o falla con errores difíciles de diagnosticar. Mientras más dura la deriva, más difícil es la actualización.

Cómo evitarlo: define una política con una ventana, por ejemplo que todo remoto debe estar en la versión mayor actual o en la anterior del framework. Automatiza los pull requests de actualización. Muestra las versiones de cada remoto en un tablero para que la deriva sea visible. Trata las actualizaciones como trabajo planificado, con tiempo en el roadmap de cada equipo.

Otros errores que vale mencionar

• Un host pesado. Lógica de negocio en el shell significa que todos los equipos deben cambiar el shell. Limítalo a layout, navegación, sesión y carga.
• Sin fallback cuando falla un remoto. Un despliegue roto deja una página en blanco. Mira aislamiento de errores y resiliencia.
• Elegir la arquitectura para un solo equipo. Con un único equipo, los costos llegan y los beneficios no.

Resumen

Más en esta sección

• Checklist de preparación para microfrontends
• Seguridad en microfrontends: qué cambia y qué hacer
• Desarrollo local con microfrontends
• Qué son los microfrontends: guía para quienes deciden