Escala tu aplicación de React sin micro-frontends

Primero, un rápido aviso legal, esta charla trata sobre la escalabilidad de tu base de código desde la perspectiva de un desarrollador y no de las actuaciones orientadas al usuario. Eso es todo para el aviso legal.

Hola de nuevo, soy Jonathan Wagner, soy gerente de ingeniería en DataUK y he estado trabajando durante los últimos 4 años en más de 10 proyectos en producción y durante los últimos 8 meses he estado trabajando con NX, que es un sistema de construcción que te ayuda a construir más rápido y hacer las cosas más rápido. Eso será el núcleo de la charla aquí. Echemos un vistazo a lo que vamos a hablar.

En primer lugar, discutiré un poco sobre el problema, qué sucede cuando escalas una base de código y luego mi experiencia para solucionarlo y lo que he aprendido en el camino, qué he intentado, qué no funcionó, qué funcionó. Así que primero, el problema. Mencioné que tener una base de código que crece significa que tu CI se vuelve un poco más lento y cuando se vuelve más lento, significa que tienes un ciclo de retroalimentación más lento, lo que significa que tus desarrolladores están insatisfechos, lleva más tiempo desarrollar funciones y al final tus usuarios están insatisfechos, lo cual definitivamente no queremos.

Entonces, cuando tu base de código crece, tienes verificación de tipos, tienes ESLint, tal vez tienes algunas pruebas de código muerto, algunas pruebas unitarias, pruebas de extremo a extremo, muchas pruebas y el tiempo de construcción y luego todo lleva un poco de tiempo y se acumula y en mi caso llevó más de 30 minutos y eso es lo que me hizo reaccionar. Idealmente quiero que mi sitio tarde 10 o 15 minutos, cuando llega a 30 minutos significa que algo ha salido terriblemente mal y quiero solucionarlo. En este caso, ni siquiera podemos ver el tiempo de construcción, simplemente se dispara, llega a 3-4 horas, lo que significa que le está costando mucho dinero a la empresa y es frustrante para todos.

Intentemos ver un ejemplo más preciso aquí, así que tenemos una base de código en crecimiento que significa que tal vez tengamos unas 800 pruebas. Imagina que tienes una solicitud de extracción donde hago un cambio de una línea, lo subes todo y el CI vuelve a ejecutar todo, lo que significa que tienes que esperar 20 minutos, tal vez 30 minutos para que las pruebas pasen. ¿Te parece normal que un cambio de una línea active 20 minutos de ejecución del CI? No lo creo. Y nx tampoco lo cree. Según la documentación de nx, en realidad dicen que la duración de la operación invocada debería ser proporcional al tamaño del cambio, y algo muy fuerte. Parece simple pero es bastante complicado de implementar. Implica un poco de almacenamiento en caché, mucho almacenamiento en caché y luego poner todo eso junto correctamente. Pero no lo sabía al principio. Así que obviamente intenté sobreingenierizar mi CI y eso significó hacer mucha paralelización, poner algunas pruebas para omitir las pruebas de frontend o backend, dependiendo de lo que se haya cambiado. Y eso significó escribir muchas reglas personalizadas, que eran complicadas e introdujeron algunas regresiones. E incluso cambiar las compilaciones de TypeScript a algo basado en Rust como swc. Y haciendo todo esto, logré algunas mejoras, llegué a 20 minutos cada una, pero eso significaba que tenía un CI complicado de gestionar. Teníamos 27 trabajos diferentes y eso significaba entender cómo todos interactuaban entre sí, cuáles eran condicionales a cuáles, y se volvió complicado de gestionar y mantener. Así que ese es el punto de partida de a dónde quería ir después. Creo que pasamos horas y horas optimizando el CI. ¿A dónde vamos desde aquí? ¿Cómo lo hacemos más rápido sin sobreingenierizarlo más? Aquí comienza el viaje. Descubriendo Annex, descubriendo un poco más sobre cómo usar Annex correctamente, cuál es el truco secreto y cómo el almacenamiento en caché pone todo junto y lo une todo.

Básicamente, eso es lo que hace Annex. Realiza reconstrucciones inteligentes, solo en las cosas que han cambiado y han sido afectadas. Para eso, utiliza caché de cálculos y te ayuda a generar cosas para que no tengas que hacerlas manualmente cada vez. Básicamente, Annex ya estaba configurado en el proyecto. No lo estábamos utilizando para el sistema de construcción. Solo lo estábamos utilizando para la gestión de monoreportes. Y cuando me di cuenta de todo lo que podía hacer, eso abrió la puerta a mucho más.

Entonces, ahora que sabemos que Annex puede hacer todo esto, ¿cómo funciona en realidad? He mencionado un truco secreto. En realidad, no es tan secreto. Se anuncia en todas partes en la documentación de Annex. La idea es utilizar bibliotecas en todas partes. Puede que te preguntes, ¿qué es una biblioteca en Annex? Es simplemente una carpeta donde puedes ejecutar algunas operaciones, como pruebas, linting, básicamente cualquier cosa que desees. Se trata del código que concierne. Así que, si miramos, por ejemplo, nuestro proyecto, aquí teníamos el frontend, que era la aplicación que realmente se implementaba y utilizaban nuestros usuarios. Y luego, todo lo demás aquí abajo son bibliotecas. Entonces, la aplicación está utilizando bibliotecas. Y luego se implementa y las bibliotecas están ahí como una forma de organizar el código en la estructura de carpetas. Y lo bueno es que puedes generarlas fácilmente, por lo que es una forma común de crear una nueva y no te cuesta mucho. Y lo que también podemos ver aquí es que, en rosa, se resaltan los proyectos que han sido afectados por el cambio. Entonces, en este caso, hice un cambio en el sistema de diseño y me muestra que algunas bibliotecas y la aplicación también se han visto afectadas. Entonces, cuando ejecuto mis pruebas o cuando ejecuto el lint, solo se van a probar y verificar esos proyectos en rosa, es decir, las bibliotecas y la aplicación. No se va a tocar nada más, porque no ha cambiado. Esa es la belleza de ello. Ese es el principio fundamental. El concepto de bibliotecas puede ser un poco confuso. Así que veamos aquí lo que significa concretamente. Este es un ejemplo de repositorio de NX, donde tienes básicamente un par de aplicaciones, cards y products, y luego algunas bibliotecas. Y si nos enfocamos en las bibliotecas, en realidad es solo una configuración anidada, una configuración de jest y luego una configuración de TypeScript, y luego todo tu código fuente en la carpeta src, y es tan simple como eso. No hay mucho más, y es todo lo que necesitas para poder ejecutar tus operaciones en cada una de esas carpetas. El beneficio adicional de utilizar bibliotecas es que te obliga a tener una arquitectura limpia, porque tienes que hacerte la pregunta, ¿dónde debo poner mi código, debería ponerlo en la misma biblioteca o crear una nueva biblioteca? Es una pregunta que, al hacértela, te obliga a iniciar una discusión, pensarlo, colocarlo en el lugar correcto y te ahorra tiempo.

evita que el código espagueti ocurra en el futuro. Entonces, básicamente, te hace ganar tiempo solo al usar NX, pero este concepto de bibliotecas, es muy bueno decirlo así, pero para que funcione, como vimos aquí, para saber que algo ya se ha construido, necesitas almacenar esa información en algún lugar, y ahí es donde entra en juego el almacenamiento en caché. NX te proporciona un almacenamiento en caché avanzado donde analiza todos los archivos fuente, la operación que estás ejecutando, por lo que si es una prueba, tienes la clave como prueba, y puedes tener la compilación o cualquier otra cosa, la aplicación que estás construyendo o la biblioteca, y luego algunas otras opciones de tiempo de ejecución o configuraciones que tienes para React, Chest o algo más. Esto significa que NX tiene una gran tabla con una clave hash y luego la salida que se supone que debe darte en términos de archivos y en términos de salida en la consola en tu dominio. Sabiendo todo esto, sabía que había algún almacenamiento en caché. Teníamos una carpeta de caché, y pensé, ¿puedo poner la caché en mi CI y usarla así tal cual? La respuesta es sí, puedes hacerlo. Supongo que es el primer paso que puedes intentar, y significa que descargas toda la caché cada vez que haces una solicitud de extracción. En algunos casos, puede crecer y crecer hasta llegar a un gigabyte, lo que significa que lleva uno o dos minutos descargarlo y descomprimirlo, y a veces puedes pasar esos dos minutos descargando y descomprimiendo, y al final ni siquiera necesitas la caché porque no es relevante para la solicitud de extracción que tienes. No está tan optimizado y no se puede compartir con los desarrolladores locales, y puedes realizar una ejecución de tareas distribuida. Menciono todo esto porque eso es algo que hace NxCloud, por lo que NxCloud ha sido desarrollado por el equipo de Nx también y básicamente configura todo esto muy fácilmente para que solo tengas que ejecutar un comando en tu terminal. Prepara todo, no tienes que registrarte, y simplemente funciona en el CI. Funciona localmente para ti cada vez que construyes algo y otro desarrollador intenta construirlo, obtiene la misma caché porque se comparte entre los desarrolladores y optimiza el orden en el que se ejecutan las tareas para que todo sea más rápido. Básicamente, deberías usar NxCloud, tiene una característica increíble, es fácil de configurar y aporta tantos beneficios y es tan fácil de usar.

Pero hemos analizado las bibliotecas, hemos analizado el almacenamiento en caché para unir todo junto. Intentemos ver lo que he intentado y dónde realmente he tenido dificultades en todo esto. Aquí vienen las lecciones aprendidas. He jugado un poco con la compilación incremental y con intentar dividir una base de código grande existente. Veamos qué sucedió aquí. Entonces, el concepto de la compilación incremental es que deseas reutilizar las salidas de tus bibliotecas. El comportamiento inicial, como el comportamiento predeterminado, es que cuando deseas construir tu aplicación frontend, utilizas una herramienta como webpack y Babel para transformar tus archivos TypeScript en JavaScript y luego tus archivos JavaScript en otra versión de JavaScript que entienda tu navegador. Y luego realizas alguna minificación para hacerlo un poco más pequeño, alguna eliminación de árbol para eliminar lo que no utilizas y eso es básicamente todo el empaquetado que ocurre dentro de webpack para que tengas un paquete pequeño que puedas lanzar a nuevos usuarios. El nuevo comportamiento sugerido por la compilación incremental de NX, en lugar de construir todo cuando lo necesitas, construyes incrementalmente cada biblioteca. Eso significa que la primera vez que deseas construirlo, construyes todas tus dependencias y luego, cuando realizas un cambio, digamos en el sistema de diseño, reconstruyes el sistema de diseño, la interfaz de usuario, las pruebas web, el dominio frontend y reutilizas la compilación anterior de los demás y básicamente vuelves a empaquetar todo en la aplicación frontend. Se supone que es más rápido y eso es lo que NX te dice en la documentación donde muestran este gráfico donde en azul podemos ver el tiempo de construcción para una compilación normal y luego para una ejecución en frío con la compilación incremental y luego otra ejecución, esta vez en caliente, para la compilación incremental. Intenté configurar esto y no obtuve exactamente los mismos resultados. Básicamente, lo que podemos ver aquí es que para la construcción desde el origen, llevaba alrededor de 60 segundos en frío y en caliente, sin diferencias, y luego, al agregar la compilación incremental, tuve 20 segundos más. Parece un poco normal porque tengo que construir todas las bibliotecas primero, pero luego esperaba que cuando estuviera en caliente no tuviera que construir las bibliotecas, solo tendría que construir la aplicación nuevamente. Así que esperaría que esta línea aquí fuera mucho más rápida. Investigué un poco más y descubrí algunas cosas. En mi configuración, teníamos una configuración personalizada de webpack donde estábamos configurando algunos cargadores de Babel adicionales, algunos cargadores de CSS y otros. La suposición que hice es que básicamente estaba construyendo mis bibliotecas de forma independiente de antemano y luego, al construir la aplicación, estaba tomando la salida de mis bibliotecas y construyendo eso

de nuevo. Básicamente, hacer todo dos veces. De ahí los 60 segundos que teníamos aquí. Así que intenté hacer algo inteligente y simplemente excluir de la sección bubble esta carpeta, para que la salida de mi biblioteca no se construyera de nuevo, y vi algunas mejoras. Así que estamos alrededor de 15 segundos aquí entre el primer intento incremental y el segundo, lo cual es un buen comienzo, pero dado el tiempo que invertí en hacer que todas las bibliotecas sean compilables y luego entender los problemas que tuvimos con Webpack y tratar de optimizar eso, no parece una buena inversión porque básicamente pasé horas en ello, tuve errores de compilación por todas partes y no veo ningún beneficio. Estoy seguro de que mi configuración de Webpack se puede optimizar mucho mejor y puedo lograr que se parezca a lo que tiene NX, pero ¿realmente vale la pena pasar horas y horas optimizándolo más? En mi opinión, aún no, tal vez en algún momento, pero hasta ahora tenemos otras formas de acelerar nuestra compilación. Una de ellas, de hecho, que descubrimos en el camino, fue simplemente actualizar nuestras dependencias. Así que esta es como una pequeña historia divertida sobre BrowserList, que básicamente utiliza una dependencia llamada canIuse que decide qué polyfill necesita tu navegador según la versión que desees y al actualizar BrowserList, se actualizó canIuse, lo que básicamente dijo que no necesitamos esos polyfills, ya no necesitamos compilar para ES5 y eso significa que solo necesitamos compilar el formato ESM y eso redujo nuestro tiempo de compilación de 12 minutos a seis minutos, lo cual nos llevó un par de horas y nos dio beneficios mucho más rápidos que las compilaciones incrementales que mencioné antes.

Otra cosa que descubrí en el camino fue una herramienta de perfilado de NX donde puedes ver y acercarte a lo que está sucediendo detrás de escena. Así que al activar una compilación de básicamente todo, puedes ver todas las dependencias aquí y puedes ver en qué orden ocurren y qué sucede en paralelo, y puede mostrarte si deberías poner más hilos en paralelo o cuál deberías dividir. Como en este caso, podemos ver que el sistema de design es bastante grande. Toma seis segundos. Tal vez el próximo candidato para dividir en dos design systems y esta vez, podríamos tener un design system específico para los forms y otro design system para todo lo demás. Así que te brinda información sobre qué podrías refactorizar a continuación

y lo que podrías estar haciendo. Así que sí, una herramienta muy buena. A continuación, veremos cómo dividir tu aplicación. Mencioné tener muchas bibliotecas. Parece muy simple y fácil así, pero ¿qué tipo de proporción deberíamos buscar? NX recomienda tener aproximadamente el 20% de tu código en la aplicación y el 80% en tus bibliotecas. Lo que eso significa es básicamente poner la mayor cantidad de código posible y luego trabajar con tus bibliotecas. Es un poco como lo que haces cuando usas bibliotecas externas como npm, pero en este caso, es tu propio código que has escrito, por lo que es un poco más seguro.

Eso suena muy bien dicho así, pero ¿cómo se ve cuando realmente lo haces en tu proyecto? Digamos que tienes dos escenarios. Cuando comienzas en un proyecto, puedes crear nuevas bibliotecas muy fácilmente y tienes un comando para automatizar eso. Es muy simple. Puedes crear bibliotecas para características, para tus elementos de IU, para el acceso a datos, utilidades y tantas como desees. Podrías tener mil bibliotecas y sería muy rápido. Solo necesitas compilar una pequeña parte cuando cambias tu aplicación. Pero se vuelve mucho más difícil cuando tienes un proyecto existente.

Digamos que tienes cientos de miles de líneas y quieres comenzar a dividirlo. Intenté hacer eso, y tenía un flujo de algunas páginas que sabía que no estaba tocando y estaba probando y construyendo cada vez que hacía un cambio. Así que quería sacar eso y básicamente no probarlo de nuevo porque sabía que no cambiaría. Así que intenté hacer eso, simplemente creando una nueva biblioteca, moviendo el código a esa biblioteca. Y luego vi errores por todas partes. No se construía, no se compilaba, había importaciones de la biblioteca a la aplicación, lo que significaba que algunas cosas eran cíclicas, lo que significaba problemas en todas partes. Y me di cuenta de que si quieres dividirlo, primero debes dividir las hojas de tu árbol. Así que en lugar de mover todas las páginas, tuve que mover los componentes uno por uno primero. Y cada vez que mueves uno, debes actualizar las importaciones, arreglar todo, hacer un commit, probar, asegurarte de que todo funcione. Así que no es un trabajo simple de simplemente crear dos bibliotecas, dividir tu código en dos, y beneficiarte de NX de inmediato. Tendrás que hacerlo poco a poco. Y mi recomendación para esto es adaptarlo a tus equipos. Entonces, si tienes equipos de dominio, por ejemplo, como en la aplicación de Spotify, donde tienes podcasts, tienes radios, tienes listas de reproducción, cada uno de ellos contiene muchas características diferentes, pero el primer paso sería que cada equipo trabaje en su biblioteca, y luego podrían tener cierta superposición, podrían tener más de una biblioteca, pero la idea es que comiencen con solo una y luego mejore y crezca. Entonces sí, comenzar con un proyecto grande, agregar NX a un proyecto grande, obtienes algunos beneficios de inmediato, pero para obtener todo el poder, lleva mucho tiempo. No sucede con solo chasquear los dedos. Será mucho refactorizar, mucho esfuerzo, y mucho entrenamiento para tus equipos. Así que tenlo en cuenta. Pero si solo tienes una conclusión rápida sobre eso, tener un sistema de construcción es el siguiente paso después de optimizar tu CI. Cuando tu base de código crece, básicamente elimina el dolor de refactorizarlo y mejora tu CI. NX es un candidato muy bueno para eso. No es el único, pero en mi experiencia, ha sido un placer usarlo. Cuando tienes una aplicación grande, dividirla es difícil. Pero cuanto antes comiences, más fácil será. Mi consejo es que comiences ahora, y avísame si tienes algún problema. Gracias a todos. No dudes en contactarme si tienes alguna pregunta, y nos vemos en la sesión de preguntas y respuestas. ¡Adiós!