Arquitectura de microfrontends

Los micro frontends extienden la idea de los microservicios a la interfaz de usuario: una aplicación web grande se divide en piezas que se desarrollan, prueban y despliegan de forma independiente. Cada pieza pertenece a un equipo distinto y todas se combinan en una sola experiencia durante el tiempo de ejecución.

Una única aplicación Angular enorme (un «frontend monolítico») vincula a todos los equipos a un mismo ciclo de lanzamiento, una misma compilación y un mismo despliegue. A medida que los equipos crecen, esto ralentiza el trabajo de todos. Los micro frontends permiten que cada equipo publique según su propio calendario.

La propiedad fundamental es el despliegue independiente: el equipo de checkout puede desplegar un nuevo flujo de compra sin recompilar ni volver a desplegar el catálogo de productos. Cada remoto es un artefacto independiente detrás de su propio pipeline.

Desde el punto de vista arquitectónico, hay un host (shell) que carga uno o más remotos. El shell gestiona el enrutamiento y el diseño de nivel superior; los remotos proporcionan áreas funcionales que se cargan bajo demanda.

Los remotos pueden combinarse en tiempo de compilación, en el servidor (SSI/edge) o en tiempo de ejecución en el navegador. La composición en tiempo de ejecución con Module Federation es la más habitual en Angular porque conserva el despliegue independiente.

Module Federation permite que una aplicación compilada exponga módulos que otra aplicación compilada carga por HTTP durante el tiempo de ejecución, compartiendo bibliotecas comunes para no duplicarlas. Es el motor de la mayoría de los micro frontends de Angular.

Cada micro frontend debería corresponder a un dominio empresarial claro (catálogo, checkout, cuenta). Unos límites de dominio bien definidos minimizan el acoplamiento entre equipos, que es precisamente el objetivo. Las responsabilidades compartidas (autenticación, sistema de diseño) se convierten en contratos explícitos.

Los micro frontends añaden complejidad real: diferencias de versión entre remotos, dependencias duplicadas si se configuran incorrectamente, depuración más difícil entre límites y fallos de carga durante el tiempo de ejecución. Adóptelos solo cuando la escala de los equipos justifique estos costes adicionales.

Para un equipo pequeño o un único producto, un monolito bien estructurado con rutas cargadas de forma diferida es más sencillo y rápido. Los micro frontends resultan rentables cuando varios equipos necesitan desplegar de forma independiente en la misma aplicación.

Para evitar una interfaz tipo Frankenstein, los equipos comparten una biblioteca de sistema de diseño y estilos globales. La coherencia es un contrato deliberado, no una casualidad, porque cada remoto se compila por separado.

Los remotos de Angular deben compartir una única copia del framework de Angular durante el tiempo de ejecución; cargar dos versiones de Angular rompe la inyección de dependencias y aumenta innecesariamente el tamaño del bundle. Herramientas como Native Federation gestionan este uso compartido por usted.

¿Cuál es el beneficio principal de los micro frontends?

Los micro frontends dividen una aplicación grande en remotos que se pueden desplegar de forma independiente y que carga un shell host, asignados a dominios empresariales. La composición en tiempo de ejecución mediante Module Federation es el estándar en Angular, que debe compartir una única copia del framework. Resuelven el acoplamiento entre equipos grandes, pero añaden costes operativos reales.