Compartir es cuidar: Mejorando el rendimiento de Micro-frontends con el intercambio de dependencias

Hola a todos. Mi nombre es Saar Becker, y hoy voy a guiarles a través de nuestro viaje en monday.com con el intercambio de dependencias entre nuestros micro-frontends. Vamos a repasar todos los desafíos que enfrentamos, todas las soluciones que intentamos y todas las lecciones que aprendimos en el camino. Pero antes de sumergirnos en los detalles de todo, hagamos un rápido repaso sobre qué son los micro-frontends.

Entonces, los micro-frontends son un patrón arquitectónico de front-end muy popular en el cual tomamos una gran aplicación de una sola página y la dividimos en aplicaciones más pequeñas. Como en este caso, tenemos el servicio A, el servicio B y el servicio C, cada uno siendo mantenido individualmente y desplegado a producción, y esto permite una mejor independencia para los equipos, un mejor alcance de nuestro sistema y un mejor aislamiento.

Pero con todas las cosas buenas que la arquitectura de front-end nos ofrece, también presenta algunos desafíos clave. Principalmente entre ellos está el tamaño del paquete. Así que lo que pueden ver aquí es que cuando teníamos una aplicación de una sola página, cargábamos React en la página solo una vez, porque existía en nuestro paquete solo una vez. Básicamente teníamos un paquete.

solo una vez, porque existía en nuestro paquete solo una vez. Básicamente teníamos un paquete. Ahora, cuando tenemos micro-frontends, React está básicamente empaquetado en cada uno de nuestros micro-frontends, lo que significa que se carga en la página tantas veces como la cantidad de micro-frontends que tenemos. Así que, en este caso, cargamos React en la página tres veces. Y, hablando en términos generales, un tamaño de paquete más grande en general en la página, cuantos más activos descargamos y más cosas cargamos en la memoria, resulta en un peor rendimiento. Resulta en tiempos de red más largos, resulta en una huella de memoria más grande de nuestras pestañas, y eso es malo.

Así que, solo para poner esto en perspectiva con algunos números, cuando cargamos tres instancias de React en la página, añadimos alrededor de 15 kilobytes de código a la página. Y si cargamos, digamos, más micro-frontends con un paquete más grande, como MobX, por ejemplo, añadimos alrededor de 630 kilobytes a la página, lo cual no es nada despreciable, y afecta el rendimiento de la pestaña, como mencionamos. Entonces, ¿qué podemos hacer al respecto? Como habrán adivinado por el nombre de esta charla y la introducción, podemos compartir, porque compartir es cuidar. Así que nos propusimos crear una especificación de cómo vamos a compartir dependencias entre nuestros micro-frontends para permitir un mejor rendimiento en general en nuestra aplicación. Así que, primero y ante todo, queremos compartir tanto como sea posible, bajo la suposición de que cuantas más cosas compartamos, mejor será el rendimiento en general. Dicho esto, queremos asegurarnos de que estamos cumpliendo con la demanda de los micro-frontends, básicamente que estamos cumpliendo con diciembre, para que nada se rompa en la página.

Sí, eso es algo bastante grande, diría yo. Y eso incluye los dos puntos. Así que primero, queremos tener una instancia de una dependencia por versión principal. Así que digamos que tenemos dos micro-frontends, cada uno de ellos está usando una medida diferente de React, uno está usando React 16, y otro está usando React 18.

Pero digamos que tenemos dos micro-frontends diferentes que usan la misma versión principal de React. Digamos que ambos están usando React 18. Queremos poder proporcionarles la misma versión de React, la misma instancia de React, para ahorrar en el tamaño del paquete. Pero hay un pequeño inconveniente en eso, y queremos asegurarnos de que mientras proporcionamos React 18 para ambos, no estamos rompiendo ninguno de ellos. Así que digamos que uno necesita React 18.1.0 y el otro necesita React 18.3.0. No podemos dar al segundo micro-frontend React 18.1.0, porque entonces corremos el riesgo de romper su código en tiempo de ejecución.

Y finalmente, en nuestra especificación, no queremos incluir ningún paquete de catálogo. Y lo que queremos decir con paquetes de catálogo es que no queremos incluir ninguna dependencia que sea en el sentido de una biblioteca muy amplia que incluya muchas funciones o componentes. Tomemos lodash, por ejemplo, donde podrías tener un catálogo de muchos tipos diferentes de funciones, pero generalmente lo que termina sucediendo es que usas solo una pequeña subsección de esas funciones, y sería un poco un desperdicio cargar la totalidad de lodash, porque no puedes tener tree-shaking con nuestra solución.

Y será más efectivo simplemente empaquetar esas pocas funciones específicas en cada micro-frontend. Así que con esa especificación en mente, salimos a construir nuestra primera solución. Y vamos a repasar lo que hicimos en tiempo de construcción y lo que hicimos en tiempo de ejecución para todas nuestras soluciones. Así que la primera iteración de nuestra solución, la llamamos solución v1. La llamamos la solución de intercambio en caliente. Así que cómo funciona, vamos a comenzar con el proceso de construcción. Primero y ante todo, queremos excluir todas estas dependencias del paquete del micro-frontend. Así que en este caso, no queremos incluir el código fuente de React en nuestro paquete.

Así que nos aseguramos de que en lugar de usar React y empaquetarlo en nuestro paquete de micro-frontend, creamos algún tipo de referencia a un objeto de ventana de algún tipo. En este caso, React 16. En segundo lugar, queremos usar esta lista cerrada de dependencias que ideamos. Incluye cosas como React, React DOM, MobX, MobX React, y así sucesivamente. Queremos usar esta lista y el paquete JSON del proyecto para crear un paquete por dependencia. Así que lo que hacemos durante la fase de compilación es revisar toda esta lista. Verificamos qué versión tiene instalada este micro-frontend y luego creamos un paquete dedicado para esta dependencia. En este pseudo código, creamos un paquete para React 18, que incluye todo su código fuente. Y también incluye un pequeño fragmento al final que expone el código fuente en la ventana bajo un nombre que incluye el nombre de la dependencia y su versión principal.

Así que una vez que tenemos eso, lo último es crear un archivo de metadatos para el micro-frontend que especifique qué dependencias compartidas y qué versión usa este micro-frontend. Así que en este ejemplo, especificamos que estamos usando React, por ejemplo, con la versión mínima de 18.1.0, que tiene el nombre global de React 18 y se carga en esta URL específica en nuestro CDN, cdn.com, y así sucesivamente. También incluye React DOM y todas las demás dependencias que tenemos en nuestra lista. Así que ahora que tenemos todo esto, excluimos cosas de nuestro paquete, creamos paquetes, los subimos a nuestro CDN, y tenemos el archivo de metadatos.

Ahora estamos listos para cargar este micro-frontend en producción, lo que incluye dos pasos básicos. En primer lugar, cuando vamos a cargar este micro-frontend en producción, queremos usar este archivo de metadatos para asegurarnos de que todo esté cargado para que este micro-frontend funcione. Así que antes de cargar realmente el código del micro-frontend, revisamos todas las dependencias compartidas que este micro-frontend necesita, y nos aseguramos de que todo esté cargado en la página. Eso es muy simple. Si no está cargado, lo vamos a cargar. Si está cargado y es compatible, que es el segundo punto, simplemente no hacemos nada. La única situación fuera de lo normal sería si la dependencia está cargada pero no es compatible con las necesidades de este micro-frontend. Así que, por ejemplo, si tomamos nuestro ejemplo anterior, digamos que tengo un micro-frontend que usa React 18.

Así que lo que hacemos es cargar React 18 una segunda vez, y esta vez React 18.3.0, y básicamente hacemos un intercambio en caliente, que es el homónimo de esta solución, lo que significa que cargamos React 18 de nuevo, y básicamente sobrescribimos el objeto window.react18, y ahora estamos usando React 18.3.0, que debería ser compatible, si Sanver lo permite, con la versión anterior, que es 18.1.0. Ahora, el primer problema con el que nos encontramos es un problema de sub-dependencias. Así que algunas dependencias en nuestra lista dependen de otras dependencias en nuestra lista, por ejemplo, MobX React depende de ambos MobX y React, que ambos existen en nuestra lista, lo que crea muchas combinaciones variables. Así que tomemos dos ejemplos, por ejemplo, digamos que uno de nuestros micro-frontends tiene MobX React 8 y usa React 16, y otro tiene MobX React 8, nuevamente la misma versión de MobX React, y usa React 18. En este caso, ambos micro-frontends van a usar la misma versión global de MobX React, que es MobX React 8, pero el problema es que MobX React bajo el capó necesita una versión muy específica de React, necesita React 18, para funcionar correctamente en tiempo de ejecución y no obtener muchos errores de React y pantallas rojas de la muerte. Entonces, ¿qué hacemos al respecto? Nuestra solución fue muy, muy simple. Queremos asegurarnos de que cuando creamos nuestras dependencias, nos aseguramos de que las creamos con nombres compuestos, y eso significa que cada dependencia también incluye en su nombre global todas sus sub-dependencias. Así que digamos que tenemos MobX React, que depende de React. Cuando añadimos la combinación de MobX React 8 y React 16, vamos a hacer React 16 guion bajo MobX React 8, y cuando tenemos MobX React 8 y React 18, vamos a hacer React 18 guion bajo, y así sucesivamente. Este es un ejemplo simplificado. Podríamos terminar con una situación donde tengamos como tres sub-dependencias de diferentes niveles y podríamos terminar con un nombre compuesto muy largo, pero eso básicamente asegura que los micro-frontends y sus sub-dependencias obtengan la referencia correcta en producción. Eso también nos obliga a actualizar el archivo de metadatos para reflejar este cambio e incluir sub-dependencias.

Así que esto cambia un poco nuestra solución. En lugar de construir con un nombre simplificado, usamos la misma lista con las mismas versiones que obtenemos de Package.json para crear el paquete con nombres compuestos por dependencia. Esta es la única diferencia. Todos los demás pasos en el proceso de construcción y en el proceso de tiempo de ejecución permanecen iguales, y eso fue todo para este problema, pero nos encontramos con un problema diferente. Lo que pensamos que sucedería cuando intercambiamos en caliente dependencias en producción es lo siguiente. Digamos que cargamos nuestro primer micro-frontend que usa React 18.1.0 y hace referencia a window.react18, y ahora digamos que cargamos un segundo micro-frontend que usa React 18.3.0. Como mencionamos antes, React 18.

1.0 no es compatible con 18.3.0, que es lo que nuestro segundo micro-frontend necesita. Así que cargamos React de nuevo y reemplazamos el puntero window.react18 para apuntar a nuestra nueva versión de React, así que cargamos React dos veces. Lo que esperábamos que sucediera es que ambos de nuestros micro-frontends iban a referenciar window.react18 en el código de tiempo de ejecución, y todo estaría genial, pero lo que realmente terminó sucediendo es que nuestro primer micro-frontend mantuvo la referencia de memoria a la primera instancia de React que cargamos en la página. Así que en lugar de usar la misma nueva instancia que nuestro segundo micro-frontend, siguió usando la instancia antigua, lo que significaba que no fue recolectada por el recolector de basura y en realidad cargamos React dos veces en la página, lo cual pierde un poco el sentido de lo que estamos tratando de hacer aquí. Así que esto nos llevó a revisar toda nuestra solución y básicamente crear una versión v2 de nuestra solución, que llamamos dependencias globales. Así que las dependencias globales son muy similares a la solución anterior que teníamos tanto en el proceso de construcción como en el proceso de tiempo de ejecución. La única diferencia es que durante el proceso de construcción de nuestros micro-frontends, también actualizamos algún tipo de archivo de metadatos global que tenemos, que mantenemos en el servidor. Y básicamente, este archivo de metadatos global contiene referencias a qué micro-frontend en nuestro sistema tenía la versión más alta por mayor de nuestras dependencias. Así que en este ejemplo simplificado, podemos ver que, por ejemplo, si necesitas usar React18 en tu micro-frontend, y no importa qué micro-frontend seas, sabemos que micro-frontend1 tiene la versión más alta de React18 posible en el sistema. Así que esta podría ser una situación en la que, por ejemplo, tenemos micro-frontend1 usando React18.7.0 y micro-frontend3, por ejemplo, usa React18.3.0. Cuando micro-frontend3 se carga en la página, va a usar la versión de React18 que es proporcionada por micro-frontend1 y existe en esta URL. De esta manera, tenemos una lista con todos los, incluyendo los nombres compuestos y todas nuestras dependencias por versión mayor a través de nuestro sistema.

Y eso es porque no está siendo usado directamente por los propios micro-frontends. Está siendo usado por un paquete diferente, React Popper en este caso. Así que eso significaba que nuestro proceso no había registrado que estaba siendo usado. Y de hecho, porque no está instalado en el package JSON de los micro-frontends, básicamente no creó un paquete dedicado para popperjs, y no lo incluyó en los metadatos de ese micro-frontend. Así que eso significaba que no estábamos obteniendo tanto como podíamos de nuestra solución, y no estábamos compartiendo tanto como pensábamos. Así que la solución aquí fue bastante simple. En lugar de usar el package JSON del proyecto para obtener la versión de las dependencias compartidas y determinar cómo crearlo, intentamos resolverlo usando require resolve, que es una función de node muy simple y ordenada que te da una ruta de tu dependencia que especificas. Esto nos lleva a la solución V versión 2.1, que es similar a V2. La única diferencia es que todavía usamos la lista, la lista cerrada que tenemos, pero en lugar de usar el package JSON del proyecto para obtener las versiones de las dependencias compartidas y crear nuestros paquetes para ellas, ahora usamos require resolve, que realmente nos da la versión instalada y todo está genial. Y en este punto, hemos estado funcionando con esta solución durante mucho tiempo, hasta que encontramos nuestro cuarto problema.

Así que nuestro cuarto problema fue que tenemos múltiples versiones mayores en el mismo paquete. Así que déjame pintar un cuadro para ti. Digamos que nuestro micro-frontend está usando MobX, está instalando MobX6, directamente, lo instala en su package JSON y lo usa para construir su almacén de datos. Y digamos que una de nuestras dependencias transitivas, en este caso, instalamos el paquete A, que usa el paquete B, que a su vez usa MobX5, por ejemplo. Lo que terminó sucediendo es que ambos usarían MobX6, porque nuestra solución, básicamente, si recuerdas, estamos revisando la lista cerrada, estamos haciendo require resolve, y vamos a obtener MobX6. Así que el paquete B tendría una referencia para usar MobX6 en producción, lo que terminó, lo que nos dejó con referencias rotas en producción, lo cual obviamente fue bastante malo. Así que nuestra solución para eso fue bastante simple. Queríamos crear, en realidad no tan simple, queríamos crear referencias a versiones mayores por importación en lugar de usar el package JSON del proyecto. Así que cómo se ve eso en nuestro proceso de construcción, esto afectó mucho nuestro proceso de construcción.

Así que en lugar de revisar nuestra lista cerrada, nuestra lista codificada, y crear paquetes por dependencia instalada, lo que hacemos ahora es que cuando construimos nuestro paquete principal, básicamente, recordamos qué dependencias, cuál de las dependencias en la lista usamos, y de dónde se usó. Así que cada vez que encontramos un uso de una de nuestras dependencias compartidas, básicamente intentamos resolverlo desde esa ruta específica. Así que digamos que encontramos el uso en nuestro paquete principal, hacemos require.resolve desde esa ruta específica. Y digamos que lo encontramos de nuevo en algún tipo de dependencia transitiva, hacemos require.resolve desde esa ruta. Así que eso podría dejarnos con dos usos de la misma dependencia compartida, pero están siendo usados desde diferentes rutas en nuestros módulos node, lo que podría significar que están siendo usados con diferentes versiones mayores. Así que ahora que tenemos todas estas referencias que creamos durante el proceso de compilación de nuestro paquete principal, ahora podemos usar esa misma memoria para crear un paquete por dependencia con nombre compuesto por versión mayor. Así que de nuevo, cómo se vería eso, afectaría el archivo de metadatos de nuestro micro-frontend, que ahora podría incluir múltiples versiones mayores por paquete, por dependencia compartida, pero ahora tenemos referencias funcionales en producción, lo cual es significativamente más importante. Nuestro quinto y último problema que encontramos son las dependencias anidadas. Así que el problema que tenemos es que podríamos tener algunas dependencias en nuestra lista que no están siendo usadas directamente por nuestros micro-frontends. Así que digamos, por ejemplo, que tenemos popperjs slash core, que está siendo usado por react-popper. Así que lo que terminó sucediendo es que cuando revisamos el paquete principal de nuestros micro-frontends, no encontramos ningún uso de popperjs slash core.

Nos encontramos con ellos solo cuando construimos el paquete para react-popper, que también está en nuestra lista. Así que eso significaba que si solo miramos el paquete principal de nuestros micro-fondants y solo recordamos qué dependencias usamos cuando construimos ese paquete, terminamos con referencias faltantes. Así que en este caso, popperjs slash core. Así que la solución para eso fue aplicar esa misma lógica de construcción de dependencias, esa misma memoria de recordar lo que usamos recursivamente para cada uno de nuestros paquetes de dependencias, así como nuestro paquete principal.

Así que lo que eso parece en términos de nuestro proceso, en lugar de hacer todo este proceso de recordar solo para nuestro paquete principal, aplicamos la siguiente lógica. Mientras todavía tengamos algunas dependencias por construir, queremos usar esa memoria para crear un paquete por dependencia con un nombre compuesto por versión principal, y cuando construimos ese paquete, recordamos lo que usamos. Así que este proceso básicamente asegura que sigamos construyendo nuevos paquetes de dependencias. Obviamente, para aquellos que aún no hemos construido. Ahora tenemos todos nuestros paquetes listos para usar en producción. Todos los demás pasos en el proceso de construcción y el proceso de ejecución permanecen prácticamente iguales.

Eso es básicamente todo. Esa es la solución con la que terminamos hoy, en Monday. Creo que una de las cosas que más temíamos era que íbamos a tener rupturas en producción. Por supuesto, todo esto parece muy delicado y propenso a romperse. Así que tengo que decir que durante los tres años que hemos estado ejecutando esta solución, no hemos tenido ningún problema en términos de Sanver o paquetes que no cumplan o se rompan o algo así. Es importante notar que implementamos muchos interruptores de apagado y mecanismos de seguridad alrededor de esta solución. También se lanzó como una solución experimental a todos nuestros micro front ends. Lo implementamos de manera lenta y gradual durante el transcurso de aproximadamente seis meses o algo así. Y ahora es el predeterminado en todos nuestros micro front ends. Y está funcionando muy bien.