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

Buenas noches a todos. En el mundo del desarrollo agéntico, donde los agentes están haciendo las cosas mucho más rápido, así 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í pueden ver cómo podemos reducir su carga de CI en un 65% para más de 200 paquetes de monorepos. Aquí estoy, Kartik Shanmugam, trabajando como ingeniero de plataforma web en 6th SE.

Así que, aquí, veamos cuál podría ser el problema y cómo podemos solucionarlo. Pero en general, si su pipeline de CI está funcionando demasiado lento, entonces eso significaría que podría estar mintiéndole. El primer pensamiento, lo 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 tenemos 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.

Entonces, lo que teníamos, tenemos una gran plataforma de TypeScript. Tenemos un monorepo con más de 200 paquetes con 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, imaginen, en un monorepo tan grande, un solo cambio en las bibliotecas centrales, cualquiera 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.

Entonces, pensamos, está bien, esto no es bueno. Así que, luego 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%. Vamos a profundizar 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 el build. Entonces, como ya les dije, tenemos este monorepo de más de 200 paquetes con más de 70 micro frontends. Monorepo de paquetes con más de 70 micro frontends. Y antes de NX, sí, para cada commit, necesitábamos ejecutar el comando de compilación para todos los más de 200 paquetes, y luego necesitábamos desplegar todos los más de 70 micro frontends. Pero, ¿por qué hacemos el comando de compilación? Porque en caso de que haya problemas o errores que surjan, dado que tenemos este compilador estático, eso detectaría los problemas de antemano antes incluso de ir a 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í? Digamos, por ejemplo, que tienes un archivo llamado price.ts, y eso está en 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 cambio 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, a partir de eso, identificamos que más de 40 micro frontends tienen que ser desplegados.

Entonces, esto sucedió para cada commit en este archivo en particular, price.ts. Esto está bien. En lugar de ejecutarse 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 explosión. Pero pensamos que aún podíamos reducir el radio de explosión 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 solo compilar 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 micro frontend en particular. Luego pensamos, está bien, eso suena genial. Entonces, 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 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 relacionados de los paquetes dependientes. Pero, ¿necesitaríamos desplegarlos todos por un cambio? Luego pensamos, está bien, hacemos esta compilación, veamos qué salida obtenemos de la 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á usando. Por ejemplo, tenemos este core package. Y el archivo que quiero modificar es price.ts. Entonces, cuando ejecuto la compilación en un MFE en particular, según el diagrama aquí, podemos llamarlo como MFE card. Entonces, 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 que intentamos hacer 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á usando este módulo price en absoluto. Porque es solo un módulo de búsqueda. Luego, pensamos, está bien, podemos compilar las aplicaciones de consumo final afectadas, pero no desplegar todo. Solo desplegamos los micro frontends originalmente afectados.

Entonces, 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. Entonces, 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, por lo que los llamamos hojas.

Entonces, compilamos solo más de 40 paquetes. Y entre ellos, obtenemos la salida de compilación de TS y verificamos, tomamos el archivo de cambio y lo encontramos en esa salida de compilación de 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. Y ahora aquí tenemos la compilación de más de 40 paquetes y el despliegue de solo más de 10 micro frontends. Podrías ver la proporción. 100 es a 40, mientras que aquí tenemos 40 es a 10. Así que, eso es una gran reducción de tiempo que obtenemos con este algoritmo.

Así que, sí, eso es. Solo confiando en NX, sí, desplegar más de 40 MRFs. Usar NX y también la salida de TS build info. Ahora solo desplegamos más de 10 micro frontends. Podrías ver de 40 a 10. Entonces, el siguiente nivel, ¿qué intentamos obtener aquí? Runners autohospedados y caché S3. Caché S3. Sí, tenemos runners de GitHub. Podemos usar runners de GitHub para nuestra tubería de CI, todo bien, sin problemas, bien. Pero tenemos algo de paralelismo en nuestra tubería de CI. Pero en este caso, no toda la tubería, lo que sea que paralelizamos, no 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 capacidad media. Así que, el CI principal, sí, por supuesto necesita un runner con capacidad máxima. Pero las acciones paralelas como desplegar, probar, esas cosas no necesitarían el runner con alta capacidad. Así que, podemos ir con la capacidad media para esos runners. Pero, ¿es posible configurar esto con runners de GitHub? Investigamos un poco allí, pero no pudimos hacerlo. Así que, 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 tubería requeriría runners de alta capacidad y qué etapa en nuestra tubería requeriría runners de baja capacidad. Así que, con eso, estábamos dividiendo toda nuestra tubería 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. Y dado que estamos usando NX, tenemos la ventaja de NX cache. Así que, eso estaría capturando la salida de compilación, la salida de pruebas, todo bien. Y el caché vive en GitHub. Así que, autohospedado en nuestra propia instancia de AWS en EC2 y el caché, lo que tenemos en GitHub. Así que, hay una conexión de red en curso para cada commit en el CI entre GitHub y nuestra propia instancia de AWS EC2. ¿Es bueno? No, ciertamente no. Porque había mucha comunicación de red entre ellos y eso realmente 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, eso está bien. Pero, ¿por qué no tener este caché también dentro de nosotros? Así que, sí, teníamos, pudimos, configuramos 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 un CI. Antes teníamos runners alojados en GitHub y caché, y ahora nos movemos hacia un runner EC2 con caché S3 en la misma región. Perfecto.

Y ahora pasemos al siguiente nivel, 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 estuvo presente durante años en nuestra tubería de CI. El primer problema es Type Explosion. Entonces, ¿qué es Type Explosion? Déjenme darles un ejemplo. Seguro, como, todos ustedes, quiero decir, todas las empresas tendrían sus propios componentes de tipografía para ellos para el frontend web. Así que, este componente de tipografía, tenemos un escenario donde el equipo de desarrollo puede realmente extender este componente de tipografía a un elemento definido por el usuario específico, lo que sea que quieran dirigir. Y este específico elemento definido por el usuario puede ser genérico. No podemos definir nada en él.

Entonces, ¿qué hicimos? Tipamos 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, todos los stacks se compilaban nuevamente, se incluían en la build, lo cual es realmente un desperdicio. Gracias a la IA. Aquí, quiero decir, con esto, lo que finalmente obtuvimos, la IA no solo nos ayuda a lanzar nuevos productos, sino que también puede ayudarnos a corregir los errores que teníamos. Con la IA, estábamos ejecutando esta compilación de TypeScript y descubrimos que este elemento particular jsx.intrinsic estaba causando un gran problema. Esa fue una parte particular.

La siguiente parte particular son los barrel files. Por supuesto, dado que estamos usando un monorepo, teniendo múltiples paquetes, definiríamos múltiples barrel files para facilitar la exportación e importación. Pero eso también estaba causando un gran problema silenciosamente. Entonces, debido a esto, cambié en uno de los micro frontends. Cuando compilamos ese micro frontend, tomaba alrededor de 60 a 70 segundos. Imaginen una compilación en un micro frontend tomando alrededor de 60 a 70 segundos. Entonces, ¿qué hicimos? Restringimos el primero, la explosión de tipos. Restringimos nuestro tipo para que, por ejemplo, para la tipografía, el caso de uso que expliqué para la tipografía, no necesitamos que se incluyan todas las posibles etiquetas HTML 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, la etiqueta SVG y todas estas cosas.

Así que hicimos que este tipo fuera mucho más restrictivo. Y los barrel files. Sí, esto es algo que estamos haciendo ahora. Hay muchos barrel files en nuestro monorepo, que estamos tratando de eliminar uno por uno. Todavía estamos en ello. Pero sí, 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 tomaba 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 mucho nuestro CSV.

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 PMPM. Sí, estábamos usando NPM y luego Yarn Classic, pero la gestión de dependencias era deficiente y por eso nos movimos hacia PMPM. Y sabes, con PMPM, la gestión de dependencias es mucho más rápida, sencilla, fácil de romper y todas esas cosas. Así que, migramos hacia PMPM. 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. Como les dije, el escenario de lo que teníamos que desplegar más de 10 micro frontends. Las traducciones ya están integradas en un 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 que tal vez podríamos mover las traducciones fuera del CI. Así que, por lo tanto, desacoplamos completamente la traducción y eso nos ayudó a reducir un poco más el tiempo de ejecución del CI.

Y la tercera cosa más importante que hicimos aquí, las pequeñas victorias, pruebas paralelizadas. 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. Así 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 tomado para ejecutar el trabajo de prueba completo se redujo de 30 minutos a 10 minutos. Así que, con todas las cosas que les conté, pudimos lograr una reducción del 65% en nuestro tiempo total de construcción y prueba de 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 el costo 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. Entonces, ¿qué tenemos ahora? Un cambio central en la biblioteca central de 75 minutos a un descanso para el brunch y cambiando en una de las aplicaciones de microfinanzas, el tiempo de descanso para el brunch se redujo a un tiempo de cambio de café. Pero de todos modos, gracias a la IA también por ayudarnos a hacer algún análisis aquí. Gracias a todos. Gracias.