Así como los microservicios dividen el backend, los micro front-ends dividen la interfaz de una aplicación grande en partes que distintos equipos pueden desarrollar y desplegar por separado. En proyectos empresariales hemos trabajado este enfoque con Angular y Module Federation. Estas son nuestras conclusiones.
El problema que resuelven
Imagina un portal interno con módulos de clientes, pagos, reportes y administración, mantenido por cuatro equipos. Con una sola aplicación Angular, cada cambio obliga a compilar y desplegar todo, los conflictos en el repositorio son constantes y una actualización de dependencias se convierte en un proyecto en sí mismo. Los micro front-ends permiten que cada equipo sea dueño de su módulo de principio a fin.
Cómo funciona Module Federation
Module Federation permite que una aplicación cargue, en tiempo de ejecución, código compilado y desplegado por otra. Hay dos roles:
- Host (o shell): la aplicación principal. Tiene el menú, la autenticación y el enrutamiento de primer nivel.
- Remotes: cada micro front-end. Expone componentes o rutas que el host carga bajo demanda, desde su propia URL.
En el enrutamiento del host, una ruta como /pagos carga dinámicamente el módulo expuesto por el remote de pagos. Las dependencias comunes (Angular, RxJS, la librería de componentes) se declaran como compartidas para no descargarlas varias veces.
En las versiones recientes de Angular, que usan el nuevo sistema de build basado en esbuild, la alternativa más usada es Native Federation, que sigue la misma idea pero apoyándose en estándares del navegador como los import maps.
Lo que funcionó bien
- Despliegues independientes: cada equipo publicaba su módulo sin coordinar ventanas de despliegue con los demás.
- Repositorios más pequeños: compilaciones más rápidas y revisiones de código más enfocadas.
- Migraciones graduales: se pudo modernizar un módulo a la vez en lugar de reescribir todo.
Errores que conviene evitar
- Versiones desalineadas: si el host y un remote usan versiones mayores distintas de Angular, aparecen errores difíciles de rastrear. Definan una política de actualización conjunta.
- Dividir demasiado: un micro front-end por pantalla multiplica la complejidad. La división debe seguir los dominios del negocio, no los componentes.
- Estado global compartido: si todos los módulos leen y escriben el mismo estado, se pierde la independencia. Es mejor comunicarse con eventos o con parámetros de URL.
- Estilos que se pisan: sin un sistema de diseño común y estilos encapsulados, cada módulo se ve distinto. Una librería de componentes compartida es casi obligatoria.
- Olvidar el rendimiento: cada remote es una descarga adicional. Hay que medir el tiempo de carga y precargar lo que se usa siempre.
¿Lo necesitas?
Si tu aplicación la mantiene un solo equipo, la respuesta probablemente es no: una aplicación Angular bien organizada en rutas con carga diferida da casi los mismos beneficios con mucha menos infraestructura. Los micro front-ends empiezan a compensar cuando hay varios equipos autónomos, ciclos de publicación distintos o una aplicación heredada que se quiere modernizar por partes.
Como con los microservicios, la pregunta clave no es "¿qué es lo más moderno?" sino "¿qué estructura le permite a mi equipo entregar valor más rápido y con menos riesgo?".