Escalando Monorepos de JavaScript a Nivel Empresarial: Lecciones de Más de 200 Paquetes

Estoy seguro de que te gustará esto. Vamos a echar un vistazo. Buenas noches a todos. En el mundo del desarrollo de agentes, donde los agentes están haciendo las cosas mucho más rápido, también debería ser nuestro CI, para que pueda mantener el ritmo con los agentes. Pero los monorepos empresariales, en realidad están creciendo tanto. Pero eso también significaría que también eran lentos. Y por lo tanto, bienvenidos a la charla, metamorfosis de monorepos. Aquí puedes ver cómo podemos reducir tu carga de CI en un 65% para más de 200 paquetes de monorepos.

Así que aquí estoy, Karthik Shanmugam, trabajando como ingeniero de plataforma web en 6SC. Así que aquí, veamos cuál podría ser el problema y cómo podemos solucionarlo. Pero en general, si tu pipeline de CI está funcionando demasiado lento, entonces eso significaría que podría estar mintiéndote. El primer pensamiento que podría venir a nuestra mente es tal vez podemos aumentar la capacidad, pero no. Ese no es el problema. El problema es el desperdicio. En nuestro CI, tal vez tengamos mucho desperdicio que está funcionando, que está consumiendo más ancho de banda, más energía, y por lo tanto el CI podría estar funcionando demasiado lento.

Así que lo que teníamos, tenemos una gran plataforma de TypeScript. Tenemos un monorepo con más de 200 paquetes, pero más de 70 micro frontends. Y aquí tenemos más de 10 equipos de producto que están contribuyendo a este monorepo. Así que imagina en un monorepo tan grande, un solo cambio en las bibliotecas centrales, lo que sea que tengamos, Esto tomó alrededor de 75 minutos, que es casi una hora y media, para ejecutar todo el CI y luego hacer que el producto esté disponible para los testers o para los desarrolladores o para el equipo de producto para validarlo. Pero 75 minutos, es realmente mucho. Para incluso un solo commit, necesitas esperar esa cantidad de tiempo. Así que pensamos, está bien, esto no es bueno.

Entonces tuvimos varias ideas sobre cómo solucionarlo. Y así terminamos con tres ideas principales, que podrían ayudarnos a abordar este particular fallo de CI, lentitud de CI, y eso nos ayudó a mejorar nuestra velocidad de CI en más del 65%. Así que profundicemos en cada una de estas ideas, como qué hicimos y cuál es el resultado, lo que obtuvimos de esa idea.

La primera gran idea que tuvimos es crear la build. Así que como ya te dije, tenemos este monorepo de más de 200 paquetes con más de 70 micro frontends. Y antes de NX, sí, para cada commit, necesitaríamos ejecutar el comando de compilación para todos los más de 200 paquetes, y luego necesitamos desplegar todos los más de 70 micro frontends. Pero ¿por qué hacemos el comando de compilación? Porque en caso de que haya algún problema o error que surja, dado que tenemos este compilador estático, eso detectaría los problemas de antemano antes incluso de desplegar. Así que por esa razón, teníamos este comando de compilación, y estaba funcionando bien. Gracias a NX. Con NX, pudimos reducirlo a la mitad. Pero ¿cómo lo hicimos?

Entonces, ¿en qué ayudó NX aquí? Por ejemplo, tienes un archivo llamado price.ts. Y ese es el paquete principal. Y este paquete principal se está utilizando como una dependencia en más de 100 paquetes. Y entre esos más de 100 paquetes, tenemos más de 40 micro frontends. Así que con la ayuda de NX, pudimos identificar cuáles son los paquetes afectados por ese particular cambio. Solo reitero los paquetes afectados, pero no los paquetes originalmente afectados. Así que aquí, en un solo cambio en price.ts, pudimos observar que los más de 100 paquetes estaban siendo afectados. Así que compilaríamos todos los más de 100 paquetes. Y luego de eso, identificamos que más de 40 micro frontends tienen que ser desplegados. Así que luego desplegamos esos más de 40 micro frontends. Así que esto sucedió para cada commit en este archivo particular, price.

This is fine. En lugar de ejecutar para más de 200 paquetes y desplegar más de 70 micro frontends, podemos reducirlo a más de 100 y más de 40. Pero, ¿es esto lo que queremos? ¿Es esto lo que queremos para cada commit en este archivo price.ts? No. Ciertamente no. Entonces, ¿qué hicimos? Sí, por supuesto, NX nos estaba ayudando a reducir el radio de impacto. Pero pensamos que aún podíamos reducir el radio de impacto para que nuestro CI pudiera ejecutarse más rápido.

Entonces, ¿qué hicimos? Primero, pensamos, está bien, tenemos más de 200 paquetes y más de 70 micro frontends. ¿Necesitaríamos compilar más de 200 paquetes? ¿Por qué no compilar solo más de 70 micro frontends? Porque compilar un micro frontend también compilaría los paquetes, cualquiera que se declare como dependencia. Compilaría los archivos, cualquiera presente dentro de los paquetes dependientes para un particular micro frontend. Luego pensamos, está bien, eso suena genial. Así que en lugar de, en general, en lugar de compilar más de 200 paquetes, podemos simplemente compilar los más de 70 micro frontends. Así que esto también compilará los paquetes dependientes.

Así que ese es el primer paso, lo que pensamos. En lugar de hacer la compilación en todos los paquetes, compilamos solo las hojas. Entonces, ¿qué queremos decir con las hojas? Así que considera que en un árbol, los micro frontends son los últimos, que no serían consumidos por ningún paquete adicional. Así que son los que quedan solos, que no serían consumidos más. También podemos llamarlos como las aplicaciones de consumo final. Entonces, ¿qué harías? Compilaríamos solo esas aplicaciones, solo los micro frontends, que a su vez compilarían todos los archivos posteriores de los paquetes dependientes. Pero, ¿necesitaríamos desplegarlos todos por un cambio? Luego pensamos, está bien, hacemos esta compilación.

Entonces, el archivo de salida, lo que teníamos es este ts buildinfo. Y sorprendentemente, este ts buildinfo tenía los archivos, exactamente el número de archivos que ese micro frontend en particular está utilizando. Por ejemplo, tenemos este core package, y el archivo que quiero modificar es price.ts. Así que cuando ejecuto la compilación en un MFE particular, según el diagrama aquí, podemos llamarlo como MFE card. Así que cuando ejecuto la compilación en este MFE card, el ts buildinfo, lo que se produjo de esta compilación, se puede ver que tenemos el archivo price.ts incluido en este MFE card desde el core package. Lo mismo cuando intentamos hacerlo en el MFE search, que no incluye este componente price en absoluto, identificamos que el core package está allí, pero price.ts falta aquí.

Eso es cierto. Porque MFE search no está utilizando este módulo price en absoluto porque es solo un módulo de búsqueda. Entonces pensamos, está bien, podemos compilar las aplicaciones de consumo final afectadas, pero no desplegar todo. Solo desplegamos los micro frontends originalmente afectados. Así que en este caso, las aplicaciones de consumo final afectadas serían MFE card y MFE search. Pero la aplicación de consumo final originalmente afectada aquí sería MFE card. Así que en este caso, solo podemos desplegar MFE card y no necesitamos desplegar MFE search. Así que eso es lo que obtuvimos aquí. Podrías ver con NX, identificamos que de 200 paquetes, solo 100 paquetes se vieron afectados. Tomamos eso.

Y luego tenemos un filtro. Con ese filtro, identificamos que más de 40 paquetes son los paquetes de consumo final, que no están siendo consumidos por nadie. Así que lo que llamamos hoja. Así que compilamos solo más de 40 paquetes y entre ellos, obtenemos la salida de compilación TS y verificamos, tomamos el archivo de cambio y lo encontramos en la salida de compilación TS. Con un filtrado adicional, obtendremos solo más de 10 micro frontends que necesitan ser desplegados. Así que podrías imaginar compilar más de 100 paquetes y desplegar más de 40 micro frontends. Ahora aquí tenemos compilar más de 40 paquetes y desplegar solo más de 10 micro frontends.

Sí, desplegar más de 40 MFPs. Usar NX y también la salida de TS build info. Ahora solo desplegamos más de 10 micro frontends. Puedes ver de 40 a 10. Entonces, la siguiente palanca, ¿qué intentamos lograr aquí? Runners autohospedados y caché S3. Sí, tenemos GitHub runners. Podemos usar GitHub runners para nuestra CI pipeline. Todo bien, sin problemas. Bien. Pero tenemos algo de paralelismo en nuestra CI pipeline. Pero en este caso, no toda la pipeline, lo que paralelizamos, necesita la capacidad completa. Podría haber algunos flujos de trabajo que necesitarían un runner con capacidad completa. Algunos flujos de trabajo que necesitarían un runner con una capacidad media.

Así que la CI principal, sí, por supuesto, necesita un runner con capacidad máxima, pero la acción paralela como desplegar, probar, esas cosas no necesitarían el runner con una alta capacidad. Así que podemos optar por la capacidad media para esos runners. Pero, ¿es posible configurar esto con GitHub runners? Investigamos un poco allí, pero no pudimos hacerlo. Entonces pensamos, ¿por qué no traer nuestros propios runners autohospedados para esto? Sí, eso funcionó. Así que esto no es dinámico, pero aunque sabemos qué etapa en la pipeline requeriría runners de alta capacidad y qué etapa en nuestra pipeline requeriría runners de baja capacidad.

Así que con eso, estábamos dividiendo toda nuestra pipeline para un conjunto de flujos de trabajo, usamos runners de alta capacidad para un conjunto de flujos de trabajo, usamos runners de capacidad media, y eso estaría dentro de nosotros. Eso resolvió una parte del problema, pero abrió otra parte del problema. Así que tenemos runners autohospedados, todo bien. Dado que estamos usando NX, tenemos la ventaja del caché de NX. Así que eso estaría capturando la salida de compilación, salida de prueba, todo bien. Y el caché vive en GitHub. Así que runner autohospedado en nuestra propia instancia de AWS en EC2 y el caché que tenemos en GitHub. Así que hay una conexión de red en curso para cada commit en la CI entre el GitHub y nuestra propia instancia de AWS EC2.

¿Está bien? No, ciertamente no, porque había mucha comunicación de red entre ellos y eso en realidad aumentó el costo. Lo que pensamos que reduciría en realidad no se redujo, más bien se anuló. Luego investigamos más y pensamos, está bien, pero ¿por qué no tener también este caché dentro de nosotros? Así que sí, creamos un bucket S3 que podría usarse como caché para todos estos propósitos. Y este bucket S3 viviría en la misma región donde alojamos nuestra instancia EC2. Así que ahora la comunicación se reduciría, el tiempo de procesamiento se reduciría, y por lo tanto, el costo también se reduce. Así que con esto, no solo se redujo el tiempo de CI, sino que también pudimos reducir el costo. Ese es el bono que tuvimos con esto. Así que sí, tenemos nuestro CI. Antes estábamos con runners alojados en GitHub y caché, y ahora nos movemos hacia el runner EC2 con caché S3 en la misma región. Perfecto.

Y ahora pasemos a la siguiente palanca, la explosión de compilación de TypeScript. Como ya les dije, estábamos compilando todos nuestros paquetes antes incluso de comenzar con el despliegue. Pero de todos modos, aquí había un problema silencioso que existía durante años en nuestra pipeline de CI. El primer problema es la explosión de tipos. Entonces, ¿qué es la explosión de tipos? Permítanme darles un ejemplo. Seguro, todas las empresas tendrían sus propios componentes tipográficos para ellos para el frontend web. Así que este componente tipográfico, tenemos un escenario donde el equipo de desarrollo puede realmente extender este componente tipográfico a un elemento definido por el usuario específico, lo que sea que quieran dirigir. Y este elemento definido por el usuario específico puede ser genérico. No podemos definir nada en él. Entonces, ¿qué hicimos? Tipificamos esta cosa particular a jsx.intrinsic elements. Pero ¿saben qué? jsx.intrinsic element en realidad incluye todas las posibles etiquetas HTML en el universo. Y debido a esto, cada vez que ejecutamos la compilación de TypeScript, todas las pilas se compilaban nuevamente, se incluían en la construcción, lo cual es en realidad un desperdicio. Gracias a la IA. Aquí, quiero decir, con esto lo que finalmente obtuvimos, la IA no solo nos ayuda a enviar nuevos productos, sino que también puede ayudarnos a corregir los errores que tengamos. Pero la IA, estábamos ejecutando esta compilación de TypeScript. Y descubrimos que este elemento jsx.intrinsic estaba causando un gran problema. Esa fue una parte particular. La siguiente parte particular son los archivos barrel. Por supuesto, al usar un monorepo, teniendo múltiples paquetes, definiríamos múltiples archivos barrel para facilitar la exportación e importación. Pero eso también estaba causando un gran problema silenciosamente.

Así que debido a esto, cambié en uno de los micro frontends, cuando compilamos ese micro frontend, estaba tardando alrededor de 60 a 70 segundos. Imagina una compilación en un micro frontend tardando alrededor de 60 a 70 segundos. Entonces, ¿qué hicimos? Restringimos eso, el primero, la explosión de tipos, restringimos nuestro tipo. Así que, por ejemplo, para tipografía, el caso de uso que expliqué para tipografía, no necesitamos que todas las posibles etiquetas HTML se incluyan aquí. Porque en general, la tipografía podría ser div, span, párrafo, sección, main, o cualquier etiqueta posible que pudiera ayudarnos a formatear el texto. Pero no queremos la etiqueta de imagen, etiqueta SVG, y todas estas cosas. Así que hicimos este tipo mucho más restrictivo.

Y archivos barrel. Sí, esto es algo que estamos haciendo ahora. Hay muchos archivos barrel en nuestro monorepo, que estamos tratando de eliminar uno por uno por uno. Todavía estamos con ello. Pero ambos juntos nos ayudaron a reducir el tiempo de compilación. Para un MFV, antes, tomaba alrededor de 60 a 70 segundos. Pero ahora solo toma 30 a 30 segundos. Así que en general, para un commit en el PR, el CI, la parte de compilación, que estaba tomando alrededor de 35 minutos, ahora se redujo a 10 a 15 minutos. Vean una gran mejora que tenemos. Así que esto realmente nos ayudó a reducir nuestro tiempo de compilación en más del 60%.

Así que estas tres cosas nos ayudaron a mejorar nuestro CSV mucho. Pero, ¿tenemos más cosas que podrían ayudarnos aquí? Sí, identificamos tres cosas más pequeñas que podrían ayudar aquí. Una es pnpm. Sí, estábamos usando npm y luego YARN classic. Pero la gestión de dependencias era pobre en eso. Así que luego nos movimos hacia pnpm. Y sabes que con pnpm, la gestión de dependencias es mucho más rápida, simple y fácil de romper y todas esas cosas. Así que migramos hacia pnpm. Y la siguiente preocupación que teníamos es que algunas de las cosas que tenemos en nuestro CI son totalmente un desperdicio. Por ejemplo, las traducciones. Así que como les dije el escenario que teníamos para desplegar más de 10 micro frontends. Las traducciones ya están integradas en nuestro CI. Y la transición estaba corriendo como un minuto por micro frontend.

Así que para más de 10 micro frontends, serían más de 10 minutos. Entonces pensamos, tal vez podamos mover las traducciones fuera del CI. Por lo tanto, desacoplamos completamente la traducción y eso nos ayudó a reducir el tiempo de ejecución del CI un poco más. Y lo tercero más importante que hicimos aquí, las pequeñas victorias, paralelizamos las pruebas. Usamos NX stacks. Así que dividimos nuestros paquetes en tres ramas principales, como NX app, NX core libraries, NX business libraries. Y paralelizamos nuestras pruebas, de modo que un solo trabajo de prueba de 30 minutos ahora solo toma de 10 a 15 minutos.

Sí, están corriendo en paralelo, pero el tiempo que lleva ejecutar el trabajo de prueba completo se redujo de 30 minutos a 10 minutos. Así que con todas las cosas que les he contado, pudimos lograr una reducción del 65% en nuestro tiempo total de construcción y prueba del CI. Entonces, ¿cuáles son las lecciones que tenemos ahora? Las pequeñas victorias vienen rápido. No siempre apuntes a tener grandes victorias al principio. Apunta a cosas pequeñas, y eso podría ayudarte a obtener una gran victoria. El gráfico es una fuente de verdad. Analiza tu árbol de dependencias. Analiza dónde puedes reducir costos, y eso podría ayudarte mucho.

Y el tercer y más importante punto, desacopla las cosas. No acoples todo junto. Así que desacóplalo e intenta optimizarlo. Así que con eso, gracias a todos. Así que ahora lo que tenemos, un cambio en la biblioteca central de 75 minutos a una ruptura de rama y cambiando una de las aplicaciones de microfinanzas, nuestro tiempo de ruptura de rama se redujo a un tiempo de café. Pero de todos modos, gracias a la IA también por ayudarnos a hacer algún análisis aquí. Gracias a todos.