Dependencias compartidas y versiones en microfrontends

Compartir dependencias mantiene rápida y consistente una plataforma de microfrontends. También es el acoplamiento más fuerte entre equipos que la arquitectura deja en pie, así que necesita reglas explícitas.

Por qué se comparten dependencias

Sin dependencias compartidas, cada remoto incluye su propia copia de Angular, de RxJS y de la librería de componentes. Los usuarios descargan el mismo código varias veces. Peor aún, las librerías que guardan estado terminan con varias instancias: dos routers, dos copias del servicio de autenticación, cada una con una idea distinta del usuario actual.

Con dependencias compartidas, el host y los remotos declaran qué paquetes tienen en común. Cada paquete se carga una vez y lo reutilizan todos.

Singletons

Algunas librerías deben existir exactamente una vez por página:

• El framework: @angular/core, @angular/common, @angular/router.
• Las librerías con estado global: la librería de autenticación, los servicios compartidos de plataforma y normalmente rxjs.

Estas se declaran como singletons. Con los plugins de federation para Angular de @angular-architects, una configuración típica es:

shared: {
  ...shareAll({
    singleton: true,
    strictVersion: true,
    requiredVersion: 'auto'
  })
}

requiredVersion: 'auto' lee el rango de versiones aceptado desde el package.json del proyecto. strictVersion convierte una diferencia de versiones en un error en lugar de una advertencia.

Qué pasa cuando las versiones no coinciden

Cada aplicación declara la versión que provee y el rango que acepta. En tiempo de ejecución, la capa de federation los compara. Hay tres resultados posibles:

Para el framework, un singleton estricto que falla de forma visible es la opción más segura. Los detalles cambian entre Module Federation y Native Federation, que se comparan en Module Federation vs Native Federation, pero los resultados son parecidos.

Una política de versiones que los equipos puedan seguir

• La versión mayor del framework es una decisión de plataforma. Todos los remotos que comparten Angular corren la misma versión mayor. El código compilado para una versión mayor no tiene garantía de funcionar con el runtime de otra.
• Las actualizaciones tienen una ventana. El equipo de plataforma anuncia la versión objetivo y una fecha. Los remotos se preparan y cambian dentro de la ventana.
• Comparte menos. Comparte el framework, las librerías con estado y el design system. Las utilidades pequeñas las puede incluir cada remoto. Compartir todo lo que hay en package.json es cómodo, y acopla a cada equipo con cada versión.
• Verifica en CI. Un paso del pipeline compara las versiones de dependencias de cada remoto con la política de plataforma y hace fallar el build cuando se desvían.

Versiones distintas del framework lado a lado

A veces una página tiene que correr dos versiones: durante una migración, cuando un equipo está atrasado con las actualizaciones, o cuando una parte usa otro framework.

El enfoque que funciona es dejar de compartir el framework para esa parte:

1. El remoto incluye su propia copia del framework y arranca su propia instancia de aplicación. No se carga como rutas lazy del router del host.
2. Se envuelve como custom element, por ejemplo con @angular/elements. El host coloca una etiqueta y pasa datos mediante atributos y eventos.
3. zone.js parchea APIs del navegador de forma global, así que debería cargarse una sola vez. Todas las versiones de Angular de la página tienen que funcionar con esa única copia.
4. Para las partes que no pueden compartir una página de forma segura, como una app AngularJS que depende de variables globales, el iframe es la alternativa. Mira Una app legacy dentro de un host de microfrontends.

Los costos: más bytes, más memoria, sin inyección de dependencias compartida y dos routers que coordinar.

Estrategias de aislamiento

Compartir una página significa compartir más que paquetes. Unas pocas convenciones evitan la mayoría de las colisiones:

• CSS. Mantén los estilos acotados a los componentes, que es el comportamiento por defecto de Angular. Ponle el nombre del remoto como prefijo a cualquier clase global.
• Globales. Nada de escribir en window fuera de un contrato pequeño y con namespace.
• Nombres de custom elements. Incluye un prefijo del equipo. Un nombre solo se puede registrar una vez por página.
• Claves de almacenamiento. Usa un prefijo por remoto en las claves de localStorage y sessionStorage.

El aislamiento de estilos se trata con más detalle en Un design system entre microfrontends.

Checklist

1. ¿Hay una lista escrita de paquetes compartidos, y de cuáles son singletons?
2. ¿Una diferencia de versión del framework falla de forma visible en un ambiente de pruebas?
3. ¿CI verifica cada remoto contra la política de versiones?
4. ¿Cada versión lado a lado tiene un dueño y una fecha de retiro?
5. ¿Se midió el efecto en el tamaño del bundle? Mira Rendimiento de microfrontends.

Más en esta sección

• Una sola apariencia entre microfrontends: tokens, componentes y aislamiento de estilos
• CI/CD para microfrontends: pipelines independientes, descubrimiento y rollbacks
• Aislamiento de errores y resiliencia en microfrontends
• Rendimiento de microfrontends: los costos y cómo controlarlos