Qué son los microfrontends: guía para quienes deciden

Los microfrontends dividen una aplicación web grande en partes que equipos distintos pueden construir y publicar por su cuenta. Esta guía explica la idea, los beneficios y la factura, sin código.

La definición corta

Una arquitectura de microfrontends divide una aplicación web en varias aplicaciones frontend más pequeñas. Cada una cubre un área del negocio, como facturación, catálogo o atención al cliente. Cada una tiene un equipo dueño, se construye en su propio pipeline y se despliega en su propio calendario.

Una aplicación delgada llamada host (o shell) las une en el navegador. El usuario sigue viendo un solo producto, con un solo login y un solo menú.

Es la misma idea de los microservicios, aplicada a la interfaz. Muchas empresas grandes dividieron su backend hace años. El frontend muchas veces quedó como una sola aplicación grande que todos los equipos tienen que modificar.

El problema que resuelven

Un frontend único y grande funciona bien mientras tiene un solo equipo dueño. Empieza a doler cuando lo comparten varios equipos:

• Un solo tren de publicación. Todos los equipos publican el mismo día, desde el mismo build. El trabajo sin terminar de un equipo retrasa a todos.
• Riesgo compartido. Un error en la pantalla de reportes puede bloquear una publicación que incluye un arreglo urgente de pagos.
• Builds y pruebas lentos. Toda la aplicación se compila y se prueba en cada cambio, aunque sea de una línea.
• Dueños poco claros. El código que todos pueden cambiar termina sin dueño.
• Actualizaciones de todo o nada. Pasar a una versión nueva del framework exige que todos los equipos se detengan al mismo tiempo.

Los microfrontends le dan a cada equipo una parte del producto que puede cambiar y publicar sin pedirles permiso a los demás.

Qué cambia para los equipos

• Dueños por área de negocio. Un equipo es dueño de una porción vertical: las pantallas, el código frontend, el pipeline y el comportamiento en producción de su área.
• Menos reuniones de publicación. Ya no hay un calendario compartido de publicaciones del frontend. La coordinación pasa a un conjunto pequeño de acuerdos escritos: cómo funciona la navegación, cómo se comparte el login, qué versión del design system está en uso.
• Aparece un equipo de plataforma. Alguien tiene que ser dueño del host, de las librerías compartidas y de las herramientas de entrega. Es un rol pequeño y permanente; el tamaño exacto depende de la empresa.

La relación entre la estructura de los equipos y la arquitectura se explica en Equipos, dueños y la ley de Conway.

Qué cambia para las publicaciones

Cada microfrontend se construye y se despliega por separado. El host averigua en tiempo de ejecución qué versión de cada parte debe cargar. Esto tiene tres efectos prácticos:

1. Un equipo puede publicar varias veces al día sin un ciclo de regresión de toda la empresa.
2. Una publicación defectuosa se revierte solo para un área. El resto del producto no se ve afectado.
3. Una actualización de framework o una migración de código legacy puede avanzar área por área. Por eso los microfrontends aparecen tanto en proyectos de modernización. Mira Reescribir, híbrido o microfrontends: cómo elegir.

Cuánto cuestan

Los beneficios son organizacionales. Los costos son técnicos, y son permanentes.

Un desglose más detallado, incluido el costo en personas, está en El costo real de los microfrontends.

Malentendidos comunes

• "Hacen la app más rápida." Normalmente hacen más difícil controlar el rendimiento de carga, porque el navegador descarga varias partes construidas por separado.
• "Arreglan el código desordenado." Un área mal estructurada sigue mal estructurada después de separarla.
• "Cada equipo puede elegir su framework." Mezclar frameworks es técnicamente posible. Cada framework adicional le suma peso a la página y conocimientos que la empresa tiene que mantener.
• "Es un proyecto con fecha de fin." La plataforma necesita un dueño mientras exista.

Preguntas que debería hacerse quien decide

1. ¿Cuántos equipos modifican el frontend hoy, y con qué frecuencia se bloquean las publicaciones entre sí?
2. ¿Podemos dibujar las áreas de negocio en una pizarra de modo que casi todas las pantallas caigan claramente en una?
3. ¿Quién será dueño del host y de las librerías compartidas? ¿Ese rol tiene presupuesto?
4. ¿Tenemos un design system o habrá que construirlo?
5. ¿Cuál es el primer paso más pequeño que probaría el enfoque en un área?

Si la respuesta a la primera pregunta es "un equipo" o "casi nunca", puedes parar aquí. Si varios equipos se esperan entre sí en cada sprint, sigue con Cuándo valen la pena los microfrontends.

Más en esta sección

• Cuándo valen la pena los microfrontends y cuándo no
• 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