Module Federation: Divide, Conquer, Share!

Usar características de front-end construidas por diferentes equipos a veces puede volverse desafiante dependiendo del enfoque elegido. Por ejemplo, si usamos una biblioteca, ¿qué pasa con la versionado y el mantenimiento? Si usamos un monolito, ¿qué pasa con las canalizaciones y los tiempos de construcción? Podemos encontrar una solución pragmática con la federación de modelos no solo para compartir las características sino también para dividir y conquistar.

Así que vamos. Hola a todos. Mi nombre es Nathalie Rochan. Soy líder técnica en Static Builders. Estoy realmente contenta de ser parte de JS Nation US y básicamente tener la oportunidad de compartir algunas experiencias y conceptos con ustedes. Así que, comencemos primero con los micro frontends. Y la federación de modelos es solo un enfoque de muchos para implementar micro frontends. Pero, ¿por qué en primer lugar considerarías implementar micro frontends, verdad? Podría ser por muchas razones. Por ejemplo, tu equipo ha crecido, tu aplicación ha crecido de una manera que el mantenimiento requiere equipos separados o simplemente tiene sentido tener nuestro proyecto dividido en diferentes partes para que pueda ser más mantenible. Y también es autónomo y desplegable independientemente, que es una de las características principales o la característica clave de un micro frontend. Correcto.

Así que podemos dividir las técnicas de micro frontend, técnicas de implementación, en dos tipos. El primero sería integrado y el otro sería tiempos de ejecución. Correcto. Así que integrado significa que los micro frontends se mantienen en modelos separados, pero aún están disponibles en tiempo de compilación. Por lo tanto, deben ser redesplegados para que un cambio sea efectivo. Un ejemplo de esto pueden ser los paquetes NPM o bibliotecas donde realmente tienes que aumentar la versión y redesplegar tu aplicación para que el cambio sea afectado. Correcto. Por otro lado, significa que estos se consumen en tiempo de ejecución, como dice el nombre. Cuando despliegas algo, por ejemplo, usando la federación de modelos, que es una forma de lograr dependencias en tiempo de ejecución, ECMAScript o System.js son otras. Las aplicaciones host o consumidoras no necesitan aumentar la versión o ser redesplegadas para tener este cambio. Una vez que una aplicación productora realiza el cambio, inmediatamente puedes ver un cambio en vivo en las aplicaciones host porque esto se consume en tiempo de ejecución en el navegador. OK. Así que aquí comenzamos a ver que ambas opciones tienen sus compensaciones. Correcto. Más como compensaciones, cosas que podrías querer considerar al elegirlas. Así que, por ejemplo, en tiempo de construcción, digamos que tienes cuatro micro frontends. Correcto.

Y uno de ellos lanzó una nueva versión. Dependiendo de cómo interactúen, digamos que dos micro frontends necesitan actualizarse. Entonces, ¿cómo te asegurarías de que ambos estén usando la misma versión? Digamos que un equipo realmente recibió el mensaje de Slack diciendo, hey, aumentamos la versión o una alerta o cualquier cosa. Lo recordaron, pero el otro equipo no. Así que podrías terminar con diferentes versiones para el usuario, lo que de alguna manera disminuye la experiencia de una sola aplicación. Pero puedes imponer esto usando diferentes herramientas. Pero comenzamos a agregar complejidad para imponer esto, como puedes ver. En cambio, en tiempo de ejecución, por ejemplo, con micro frontends, con federación de modelos, por ejemplo, resuelves el problema porque todos tendrán la misma versión tan pronto como el otro equipo despliegue. Correcto. Pero, ¿qué pasa si introducen un cambio disruptivo? ¿Qué pasa si algunas aplicaciones estaban estrechamente acopladas? Correcto. Así que la aplicación podría romperse. En este caso, podríamos querer asegurarnos de que tenemos un desacoplamiento total o que tenemos compatibilidad hacia atrás, o podríamos terminar agregando la versión nuevamente. Correcto. Así que como puedes ver, ambos tienen sus compensaciones. Aquí también hay algunas otras técnicas que puedes hacer, puedes usar para micro frontends, como web components, system.js, incluso iframes, monorepos con NX frameworks como Single SPA o Bit. Pero nos vamos a centrar en la federación de modelos. Así que veamos cómo funciona.

La federación de modelos fue introducida en Webpack 5 y este año se lanzó la versión 2.0. La forma en que funciona es habilitando el plugin en la herramienta de construcción. En este caso, estamos usando Webpack. Pero en la versión 2.0, desacopla el tiempo de ejecución de las herramientas de construcción, aumentando la flexibilidad de la carga de modelos. Así que como puedes ver aquí, definimos cuáles son nuestras dependencias remotas y los elementos que queremos exponer. Podemos exponer cualquier cosa, desde un componente hasta un proveedor de funciones. Para nuestro caso de uso, usamos algo llamado o algo que podemos llamar el patrón de estrangulamiento. Así que podemos usar modelos de una aplicación desarrollada por otros equipos. Esto se debe a que la aplicación que el otro equipo estaba desarrollando, ya sabíamos que iba a ser de alguna manera deprecada, pero necesitábamos una manera de comenzar a usarla rápidamente y que pudiéramos completar nuestra aplicación host. Así que lo que hicimos fue usar la federación de modelos para básicamente importar hooks, importar algunos proveedores que necesitábamos para obtener información de la otra aplicación, y también el componente principal que usamos para completar nuestra aplicación. Así que en este caso, voy a representar nuestro caso de uso con una aplicación de cine donde el reservador de asientos y el perfil de usuario estaban siendo desarrollados por otros equipos. Así que como puedes ver, estamos exponiendo los componentes de ambos. Y en la aplicación host, los consumimos.

Entonces tenemos dos aplicaciones productoras y un consumidor. Y como puedes ver, la aplicación es solo importante, la URL del manifiesto, ¿verdad? Y una vez que tienes actualizaciones que se hacen desde los productores, hagamos, por ejemplo, una actualización en el seat beaker. No tenemos que volver a desplegar las actualizaciones en la aplicación host. El manifiesto ya tiene todo lo que necesitas para consumir la última versión. ¿Verdad? Así que este manifiesto es el que contiene toda la información y los activos que van a ser utilizados desde nuestra aplicación host. Y esto es lo que usamos para importar y básicamente completar nuestra aplicación host.

Entonces, ¿qué pasa si esto falla o la URL muere por alguna razón? Tenemos que asegurarnos de que estos activos se estén sirviendo en algo como en un nivel alto de disponibilidad como un bucket de la industria CDN o bucket de la industria para que podamos asegurarnos de que no tengamos tiempo de inactividad o al menos disminuirlo tanto como sea posible. Y este es uno de los inconvenientes de la Federación de Modelos que la aplicación no está completa en tiempo de construcción, por lo que podríamos tener errores en tiempo de ejecución en el navegador. Pero necesitamos asegurarnos de que implementamos estas opciones de alta disponibilidad que servimos los activos y nos aseguramos de que estén saludables. Y si en caso de que algo suceda, fallamos con gracia con límites de error en el peor caso.

¿Verdad? Y como puedes ver aquí, una vez que los importamos y los consumimos, la aplicación en sí, quiero decir en el host, es bastante normal usarla. La diferencia es que estos están llegando en tiempo de ejecución y como puedes ver el navegador los está renderizando como HTML normal. Y también algo realmente importante de notar y que también se implementó en nuestro caso de uso es que ambas aplicaciones, incluso la host y la consumidora tenían su propia lógica de negocio y eran independientes. ¿Verdad? No compartimos el backend en absoluto. Y esto es bastante importante en microfrontends porque tratamos de asegurar el acoplamiento y la independencia en el despliegue. Así que tener un backend o un BFF que sea específico para cada microfrontend es importante para asegurar la independencia. Ahora, hablemos de algunas características y cosas a tener en cuenta, por ejemplo, tipos. Si pensamos en el manifiesto que estábamos viendo antes, estos están siendo consumidos en tiempo de ejecución. ¿Verdad? Pero ¿qué pasa con la seguridad de tipos? Porque realmente la necesitamos, ¿verdad? Para poder ver, quiero decir para tener la seguridad de tipos en sí, características de autocompletado y cosas. Si esto es en tiempo de ejecución, no podemos hacerlo porque no sabemos cuáles son los tipos del otro equipo. ¿Verdad? Solo tenemos una URL. Así que lo que hicimos en nuestro equipo fue extraer los tipos y crear un script para extraer los tipos del otro proyecto e importarlos en el nuestro. Pero esto es porque realmente teníamos acceso a ese repositorio y pudimos hacerlo. Pero algo que se implementó en Model Operation 2.0 es que ahora tenemos este plugin de TypeScript y el plugin Mejorado que nos permiten hacer algo similar, ¿verdad? Una vez que exponemos algo en nuestro modelo, el plugin automáticamente reconoce lo que estamos exponiendo, extrae los tipos, los guarda en una carpeta, y ahora se sirve como un activo para la aplicación host para poder descargarlo, ¿verdad? Así que cuando el host realmente va y dice, hey, quiero este remoto en mi aplicación, el plugin automáticamente reconoce e intenta descargar esa carpeta. Una vez que la carpeta se descarga, automáticamente la extrae. Pero tuvimos que hacer alguna configuración, como puedes ver aquí en nuestra configuración de TypeScript, para usarla como ruta de respaldo, ¿verdad? Así que si alguno de los tipos para cualquier elemento en el proyecto no se encuentra en el proyecto local en sí, busca los tipos en esa carpeta que fue descargada. Y esa es la forma en que obtenemos características de autocompletado y seguridad de tipos para los modelos federados. Ahora, quiero hablar sobre este concepto que se llama los sitios completamente federados. Porque cuando estábamos desarrollando nuestra aplicación, el otro equipo realmente no tenía acceso para ver cómo funcionaría su aplicación en nuestra aplicación host. Quiero decir, podrían haber descargado nuestra aplicación y realmente iniciar el servicio, ver cómo funciona, o esperar a que despleguemos la aplicación e ir al entorno de desarrollo para verlo, ¿verdad?

Como, por ejemplo, para el Boolean, algo que se estaba montando dentro de otro componente o comenzamos a tener ese tipo de problemas, ¿verdad? Además, algo que nos sucedió es que dado que esa aplicación tenía una configuración muy compleja para el backend y realmente, realmente complicadas necesidades para que se iniciara, no pudimos realmente usarlas ambas al mismo tiempo, ¿verdad? Así que lo que terminamos haciendo fue crear este modelo federado que se usaba como respaldo. Tenía una funcionalidad realmente básica que nos ayudaba a ver cómo funcionaría nuestra aplicación como un todo, quiero decir, completada con la información obtenida de la otra aplicación, ¿verdad? Pero de nuevo, era bastante como si realmente no supiéramos cómo funcionaría esa aplicación con la del host. Así que ahí es donde este concepto de sitios completamente federados podría haber sido útil para nosotros en ese momento, porque esto crea una especie de dependencia circular entre aplicaciones para que la del host no solo se convierta en un consumidor sino también en un productor. Así que como puedes ver aquí, por ejemplo, en la aplicación de teatro, la aplicación de inicio, se va a exponer a sí misma, ¿verdad? Y cuando vamos a la aplicación, también podemos consumir la aplicación del host y podemos crear un segundo script para poder iniciar nuestra aplicación con la del host, ¿verdad? Así que eso nos da un ciclo de desarrollo realmente rápido y será bastante fácil ver cómo interactúan ambas cuando, por ejemplo, necesitan, tienen algo acoplado o algún estado o algo que realmente necesita interactuar entre sí. Será más fácil de probar e incluso fácil de probar o usar para pruebas de extremo a extremo.

Además, quería hablar sobre algunas cosas, por ejemplo, el rendimiento. Y creo que es importante tener en cuenta varios factores que tenemos cuando importamos componentes de un modelo federado. Por ejemplo, el primero es que es realmente importante usar importaciones dinámicas para reducir el tamaño inicial del paquete y también poder importar y cargar estos modelos solo cuando se necesiten, ¿verdad? También, las aplicaciones waterstrap para darle a webpack la oportunidad de procesar el resto de las importaciones antes de ejecutar la aplicación y evitar condiciones de carrera. El más importante creo que es compartir dependencias porque no especificar paquetes compartidos puede resultar en duplicaciones y ralentizar la experiencia. Y no definir versiones entre bibliotecas compartidas también puede causar errores entre las aplicaciones. Y si hay bibliotecas con estado interno, tenemos que asegurarnos de hacerlas como singletons para asegurar que tengamos solo una instancia en ejecución, ¿verdad? Y ahí es donde también entra la depuración porque cuando comienzas a tener problemas de rendimiento debido a dependencias compartidas, podemos usar herramientas como Medusa donde podemos tener una mejor comprensión de cómo están conectados nuestros microfrontends y especialmente qué dependencias estamos usando y cuáles necesitan su atención. Por ejemplo, aquí nos está diciendo que una dependencia específica puede ser declarada como compartida. Y también algo realmente genial que se introdujo en Model Federation 2.0 es que las herramientas de Chrome ahora, para las herramientas de Chrome ahora tenemos un plugin, un plugin de Model Federation que podemos instalar y ver cómo está conectada nuestra aplicación y cómo se están consumiendo nuestros modelos. Así que eso es bastante genial para depurar porque si algo falla, también puedes ver qué otras aplicaciones pueden verse afectadas, ¿verdad?

También para el estilo, lo que hicimos para mantener nuestra aplicación coherente es usar el mismo kit de UI y eso nos permite reutilizar componentes construidos, evitando la personalización, ¿verdad? Tanto como sea posible. Así que si necesitábamos cambiar algo, lo cambiamos en la biblioteca del kit de UI. De esa manera evitamos presentar al usuario algo como Comic Sans en una página y Times New Roman en la otra. ¿Verdad? También, el enrutamiento es realmente importante tenerlo en cuenta. En nuestra aplicación, lo que hicimos fue usar el concepto de una aplicación shell. Que en realidad es prácticamente el host. Y el único propósito de ella es orquestar el microfront, ¿verdad? Así que el enrutamiento solo funciona dentro de la aplicación del host. Cuando realmente podemos importar los modelos con carga diferida, renderizarlos con lo necesario y básicamente manejar el enrutamiento como lo necesitábamos. Otras opciones que puedes usar también pueden ser como frameworks, por ejemplo, Single SPA. Single SPA te permite montar y desmontar componentes para mejorar el rendimiento y cargarlos en lugares específicos o rutas específicas, ¿verdad? ¿Verdad? Finalmente, la gestión de etapas. Tuvimos aplicaciones realmente estrechamente acopladas. Así que la gestión de etapas se usó básicamente desde la aplicación productora porque realmente necesitábamos obtener el estado de allí. Usamos hooks, lo que lo hizo un poco más fácil de hacer. Pero diría que si realmente quieres ir hasta el final, y si probablemente hubiéramos estado usando modelos, no solo por el patrón estrangulado, sino por diferentes casos de uso, también hay cosas como, por ejemplo, podríamos haber usado como probe drilling, pool solve, parámetros de consulta, almacenamiento local, cualquier cosa que pudiera haber evitado acoplar básicamente las aplicaciones.

Y siempre necesitamos intentar básicamente desacoplarlos. Podríamos haber intentado incluso crear un modelo federado específico para un estado y usarlos para desacoplarlos. Eso también es algo a tener en cuenta.

Y para darles algunas conclusiones, supongo que al diseñar qué enfoque usar cuando se pretende hacer crecer su aplicación, descubrirá que todo es una compensación. Todo tiene sus consecuencias y tenemos que aceptar las que más nos benefician y nos afectan menos según nuestro proyecto, nuestros equipos, nuestras aplicaciones. En nuestro caso de uso, creo que module federation fue realmente útil, como se mencionó, para el patrón de estrangulamiento. Y eso realmente nos ayudó a construir la aplicación, la anfitriona que iba a estar allí por más tiempo, ¿verdad?

, para el futuro, hasta que migremos la otra. Ahora, si nos preguntamos si deberíamos comenzar directamente con Microfrontends y cualquiera de sus implementaciones, creo que es importante preguntarnos si realmente tenemos los problemas que Microfrontend resuelve. Por ejemplo, mencionamos que la característica clave es tener independientemente el lugar, ¿verdad?, para diferentes partes del sistema. Así que esto significa que nuestro producto ha crecido y muchas de las cosas que estamos viendo en mantenimiento y cosas nos guían a separar el problema en piezas más pequeñas. Así que ahí es donde creo que podemos empezar a pensar en ello. Y sí, creo que eso es todo.