Monorepos Rápidos de React con una Alta Calidad DX

¡Hola y bienvenidos a mi charla sobre monorepos de React rápidos con una alta calidad de DX! Pero antes de continuar, permítanme presentarme. Mi nombre es Joris Schumfler, soy Director de Experiencia de Desarrollador aquí en Narwhal. También soy un Experto en Desarrollo Web certificado por Google. Soy instructor de ECHI y Embajador de Cybers.

Narwhal es la empresa detrás de NX y brindamos servicios de consultoría para empresas Fortune 500, pero no solo eso. Nuestro alcance abarca desde ayudar con el desarrollo de Angular y React, pero en particular, ayudamos con los monorepos, es decir, ayudamos a migrar a escenarios de monorepos, configurar nuevos monorepos, pero sobre todo, ayudamos a tener éxito con esos monorepos a largo plazo. También somos los creadores de la herramienta de código abierto NX. Y por si acaso te lo perdiste, recientemente también asumimos la responsabilidad de Leerna, que ahora se une a NX.

Entonces, ¿qué es NX? NX es un sistema de construcción inteligente, rápido y extensible que se puede utilizar para monorepos. Y hoy no voy a entrar específicamente en NX, pero lo estoy utilizando como un ejemplo de un conjunto de características como una herramienta de monorepo completamente funcional que puede ayudarte no solo a comenzar rápidamente, sino también a tener éxito a largo plazo. Ahora NX es muy popular. Hemos superado el millón de dólares en diciembre y probablemente alcanzaremos los dos millones por semana en junio. Es muy emocionante y muestra cuánto interés ha ganado el espacio de los monorepos recientemente.

Ahora, ¿qué son los monorepos? Rich Harris, hace un par de semanas, publicó un tweet con el que estoy totalmente de acuerdo, porque tengo la misma pregunta de las personas y tengo que responder y explicar una y otra vez. Básicamente, no estaba contento con el término monorepo. Y el problema es que monorepo implica, o lo que mucha gente piensa, es que necesitas tener un único repositorio para toda la organización. Ahora, es perfectamente comprensible por qué la gente piensa eso, pero en realidad, lo que vemos cuando trabajamos ahora, por ejemplo, con grandes empresas, es algo más como esto. Así que tienes grandes monorepos, un par de ellos dentro de tu empresa, tal vez divididos por departamento, organización o dominio, y luego también tienes los polyrepos existentes, o incluso nuevos polyrepos, que surgen dentro de esa organización. Entonces, si tienes una combinación de este tipo de paisaje y compartes cosas a través de registros, a través de registros internos, incluso los monorepos comparten algunas de las partes para el exterior. Porque si tienes algunos polyrepos que podrían beneficiarse de, digamos, la biblioteca de componentes que construyes dentro de un determinado monorepo, es posible que también quieras publicar eso en un registro, aparte de simplemente usarlo dentro de ese monorepo. Así que eso está perfectamente bien. Ahora, probablemente tener un término como repositorio multiproyecto versus repositorio de un solo proyecto sería más útil o más significativo, pero no voy a acuñar un nuevo término aquí. Así que cuando hablo de monorepos, lo que quiero decir básicamente es un único repositorio Git con dos o más proyectos distintos, y Polyrepo por otro lado es un escenario más clásico, que es bastante básico, que es como un único repositorio con un proyecto en él.

Entonces, ¿cómo se ven los monorepos? Vienen en diferentes formas. En muchos casos, especialmente en el mundo del código abierto, lo que ves es simplemente un repositorio con la colocación de código. Tienes varios proyectos allí, que no necesariamente se relacionan entre sí o tienen relaciones entre ellos, por lo que la mayoría de las veces se trata de reutilizar configuraciones de CI o utilidades comunes para ser más rápidos en la publicación en NPM, cosas así.

Pero el verdadero valor que obtienes de un monorepo es si esos paquetes se relacionan entre sí en cierta medida. Comparten código y facilitan la colaboración dentro del monorepo. De hecho, un monorepo se trata de arquitecturar tu sistema. Muchas veces tienes escenarios como este. Tienes diferentes áreas de dominio dentro de tu organización y muy a menudo existen como polyrepos separados. Pero si los fusionas en un monorepo, el escenario podría verse así. Tienes estos dominios y a medida que evolucionas tu monorepo, lo divides en subproyectos más pequeños. Tienes una aplicación por cada dominio, que puedes implementar de forma independiente, y cada dominio tiene bibliotecas específicas que no se comparten con otros dominios o con otras partes del monorepo, sino que son específicas de ese dominio en particular.

La razón principal de tener esas bibliotecas es dividir la base de código, tener equipos más organizados y poder trabajar en proyectos individuales dentro de ese espacio de trabajo, básicamente dentro de ese dominio único, y también puedes tener APIs mucho más detalladas en ese caso, lo que te ayuda a crear un código más mantenible a largo plazo. Ahora, obviamente, obtienes más beneficios una vez que también comienzas a reutilizar cosas. En la parte inferior de esta imagen, por ejemplo, puedes ver esas bibliotecas que son utilizadas mucho por los dominios de nivel superior, y esas bibliotecas suelen ser utilidades de código, como bibliotecas de autenticación, bibliotecas de registro, tal vez para calcular fechas, o incluso algunas partes más específicas para tu dominio, para tu organización. Por ejemplo, podría ser una biblioteca de componentes de interfaz de usuario que se encuentra allí, que es utilizada por varias partes de los dominios para tener una apariencia y una sensación de interfaz de usuario uniforme. Así que, ya desde esa imagen, puedes ver que una idea errónea común queda demostrada como falsa, ¿verdad? Muchas personas piensan que monorepo es igual a monolito, lo cual es todo lo contrario, porque hemos visto que incluso tenemos diferentes aplicaciones por dominio dentro del monorepo. Por lo tanto, se pueden implementar de forma independiente. En lugar de crear un monolito, lo que haces es dividirlo, en este caso, aquí abajo, como puedes ver aquí, tenemos las bibliotecas de utilidades más generales que acabo de explicar, pero esas no son las únicas. Incluso puedes tener conexiones entre dominios. Y también en esos casos, es muy útil crear, por ejemplo, bibliotecas de uso compartido dedicadas, que expongan un objeto de datos común que puede ser utilizado por otros dominios e interfaces de API comunes, de modo que los dominios puedan comunicarse entre sí. Por ejemplo, el dominio de pago podría necesitar utilidades, ya sea utilidades de interfaz de usuario, pero también utilidades de comunicación para la parte de productos de los dominios de tu organización. Y finalmente, como mencioné antes, incluso puedes tener esos nodos finales muy generales, que son algunas bibliotecas de propósito muy general, como componentes de interfaz de usuario, que también puedes querer publicar fuera del monorepo, para que los polyrepos puedan consumirlos. Ahora, como puedes ver en mi título, la parte rápida es muy importante en el monorepo, porque si te acercas a ellos de manera ingenua, puede ser fácil comenzar, pero después de un año más o menos, las cosas pueden volverse muy, muy lentas rápidamente. Y si una solicitud de extracción en CI tarda más de una hora en construirse, eso dificulta el desarrollo de nuevas funciones y ralentiza a tus equipos. Básicamente, en lugar de fomentar la colaboración, comienzas a ser perjudicial. Definitivamente, necesitas tener herramientas que te permitan construir solo lo que ha cambiado, y la mayoría de las herramientas de monorepo tienen algo que se llama un gráfico de proyectos y lo que se puede hacer con un gráfico de proyectos es, por ejemplo, si una biblioteca como aquí en la imagen del medio cambia, esas herramientas pueden recorrer los gráficos de proyectos para comprender qué necesita ser construido o probado o analizado. En este caso, puedes ver que ya podemos eliminar muchas bibliotecas y aplicaciones que no necesitan ser modificadas. Obviamente, será mucho más rápido que también ejecutar pruebas para ellas.

Incluso puedes aprovechar esto, por ejemplo, para comprender qué necesita ser implementado nuevamente, como siempre tener la última versión en producción. En este caso, puedes ver que todas las aplicaciones en nuestros dominios se ven afectadas porque es una biblioteca muy central en este caso que ha cambiado. Y probablemente querríamos implementar todas esas aplicaciones también.

Ahora, afectado es solo una parte. El caché es lo que hace que sea aún más rápido. Por ejemplo, tomemos ese mismo escenario donde. Cambiamos esas bibliotecas y todas se ejecutan en CI y una de las bibliotecas, como en la esquina superior izquierda, falla la prueba. Entonces el desarrollador las revisa, las descarga, corrige la prueba, las vuelve a enviar. Ahora no tenemos que ejecutar todas nuevamente porque todas las demás partes no se ven afectadas por el cambio que acaba de hacerse. Todavía se ven afectadas en comparación con la rama principal como master o main. Sin embargo, solo necesitamos ejecutar las pruebas nuevamente o calcular nuevamente para la biblioteca y la aplicación en la esquina superior izquierda. Porque todos los demás resultados se pueden obtener del caché. Obviamente, obtienes mucha más velocidad.

Ahora la distribución es realmente la clave aquí porque actualmente el caché, por ejemplo, en NX específicamente, de forma predeterminada es local. Es local para la estación de trabajo de cada desarrollador, lo que significa que el desarrollo local se vuelve más rápido y se acelera, pero no puedes aprovecharlo realmente, especialmente en CI. Y ahí es donde vemos que mucha gente usa el caché porque quieres asegurarte de que las solicitudes de extracción sean rápidas para fusionarse. Y para poder tener un caché distribuido, necesitas un contraparte central en el servidor, en el caso de NX es NXCloud, que te permite distribuir ese caché entre los miembros del equipo y también en CI. Y NXCloud va un paso más allá. No solo distribuye el caché real, sino que también distribuye la ejecución de tareas, lo que lo hace aún más rápido. Normalmente, en CI, lo que haces es obtener ese gráfico de proyectos que se vio afectado por el cambio. Y luego tienes un conjunto de agentes porque lo que quieres hacer es paralelizar tanto trabajo como sea posible. Y así puedes dividirlo en lotes iguales. Eso es lo que suele suceder. Ese es el enfoque más ingenuo, simplemente dividirlos en lotes iguales y distribuirlos entre los agentes. Sin embargo, lo que podría suceder es que algunos agentes sean muy rápidos porque tienen tareas que se completan en unos segundos, mientras que otros agentes tardan minutos. Y así, toda la ejecución de CI tiene que esperar hasta que todos los agentes terminen. Por lo tanto, la utilización de los agentes no es óptima. Y también el tiempo real no es óptimo al final. No es tan rápido como se esperaría. Ahora, NXCloud, por ejemplo, distribuye los cachés o distribuye no solo los cachés, sino también las tareas de manera uniforme según los datos históricos.

Y así sabe, según el gráfico, qué procesos se pueden construir en paralelo, donde básicamente pueden asignar una sola tarea a un agente porque es una tarea de larga duración y cuál debe ejecutarse en serie. Y al final, la parte de DX, aquí es donde se recopilan y envían todos los registros y artefactos al nodo principal real y se agrupan. Y desde la perspectiva de un desarrollador, si ocurre un error o desea ver la ejecución real, simplemente puede ir a los registros y los verá de la misma manera que si se hubieran ejecutado en una sola máquina.

Y es aún mejor porque todas esas tareas ahora están distribuidas en los agentes. Aquí, puedes ver una captura de pantalla de NX cloud que muestra la utilización de los agentes y cómo se equilibran también en función de los datos previos que NX cloud ha obtenido y, por lo tanto, sabe cómo paralelizar mejor esas tareas. Y obtienes incluso una visualización agradable. Entonces, cada vez que se ejecuta una PR, puedes entender en tiempo real cuántos agentes están ejecutándose actualmente, qué tareas se están ejecutando en qué agente, lo cual es particularmente importante para fines de depuración.

Ahora, esto fue un poco rápido y ya un poco entrelazado con la parte de DX, como acabamos de ver, como la visualización, por ejemplo, que te ayuda desde una perspectiva de experiencia de desarrollador a depurar cosas. Pero DX es muy importante en React, más en el escenario de monorepo en general, porque no hay nada como tener una configuración de monorepo rápida, súper completa de funciones, pero es muy difícil de usar o configurar desde una perspectiva de desarrollador. Y en NX específicamente, la parte importante es la parte de experiencia de desarrollador. Y, en primer lugar, las cosas deben adoptarse incrementalmente, ¿verdad? Por lo tanto, NX se puede configurar de dos formas principales diferentes. Puedes comenzar con una configuración central, lo que significa que no usas ningún complemento que venga con NX, solo instalas NX y lo usas en tu monorepo existente.

Y para escenarios de migración, esto es ideal porque aún puedes usar la misma infraestructura que tenías antes, y NX simplemente hará que las tareas se ejecuten mucho más rápido. Lo que aprovechas es el programador de tareas rápidas, el caché y también la ejecución de tareas distribuidas si usas NX cloud, como acabas de ver. El otro enfoque es que si comienzas de nuevo, puedes beneficiarte de configurar NX con algunas cosas preconfiguradas. Por ejemplo, puedes decir: `Sé que estoy usando una configuración de monorepo de react porque react es mi enfoque principal`. Entonces, ya puedes usar algunas plantillas preconfiguradas que vienen con NX. Y NX se asegurará de que tengas la configuración de Jest, ESLint, Prettier, configuración de Cypress lista para ti. Por lo que no tienes que preocuparte por muchas de esas cosas. Por lo general, esa es la mejor opción si estás comenzando un nuevo monorepo en este momento.

Por lo tanto, para la configuración central, es muy fácil de ajustar. Básicamente, solo ejecutas el comando npx add NX to monorepo, que lo agregaría a cualquier espacio de trabajo de npm, yarn, pnpm y simplemente lo haría mucho más rápido. Curiosamente, como mencioné al principio, asumimos el control de Seo Chip para Lerna, y ahora podemos hacer cosas muy interesantes, especialmente para tus espacios de trabajo de Lerna. Por ejemplo, en este momento, si estás usando Lerna 5.1 o superior, solo tienes que instalar NX y establecer use NX en true en tu archivo Lerna JSON, y automáticamente delegará la programación de tareas a NX, lo que hará que Lerna sea súper rápido sin que tengas que cambiar nada más, lo cual es muy importante, creo, desde una perspectiva de economía de desarrollador.

Otra cosa es la salida hermosa. Ahora, esto puede no parecer tan importante inicialmente, pero si piensas en cuántas veces miras las salidas de la terminal como desarrollador, y para reducir la carga cognitiva, NX realmente solo muestra lo más importante en este momento. Por ejemplo, no muestra la ejecución de tareas dependientes como en esta animación aquí, sino solo lo que se ejecuta, a menos que, por supuesto, ocurra algún error. Eso se resaltaría, obviamente, en grande y en rojo, e incluso si vuelves a ejecutar la tarea y se almacenan en caché, la salida es exactamente la misma. Por lo tanto, básicamente tienes una carga cognitiva mucho menor cuando analizas esos registros porque solo ves lo que necesitas en este momento. También la integración de ID.

Esto es especialmente interesante para los recién llegados, pero también si quieres explorar simplemente las capacidades que tienes, ¿verdad? Por ejemplo, para Visual Studio Code, pero también hay extensiones de la comunidad para WebZone, por ejemplo, tenemos la extensión de consola NX, que te permite navegar dentro de un espacio de trabajo NX y en el futuro incluso un espacio de trabajo de Lerna, lo que te permite explorar los comandos que puedes ejecutar, las cosas que puedes generar en ese espacio de trabajo visualmente desde Visual Studio Code.

Otra parte, la parte visual, también es muy importante al explorar el espacio de trabajo. Entonces, muchas de estas herramientas de monorepo tienen un llamado gráfico de proyecto debajo. Ahora, en NX hemos ido un paso más allá y lo hemos visualizado como una aplicación web dinámica que puedes iniciar directamente desde tu CLI. Y aquí puedes ver cómo puedes, por ejemplo, tomar dos nodos y básicamente hacer que NX visualice el camino más corto entre esos nodos, así como todos los caminos potenciales. Y puedes imaginar cómo eso puede ayudar a comprender por qué algunos nodos se conectan entre sí, como por qué existe la conexión, pero también, por ejemplo, para depurar dependencias circulares.

Y finalmente, una parte muy importante no es solo comenzar rápidamente como hemos visto en términos de ser rápido, sino también el soporte continuo a medida que tu monorepo crece. Los co-generadores son una cosa que puede ayudarte con eso, que viene con NX, lo que significa, por ejemplo, si tienes co-generadores para facilitar la integración de desarrolladores junior, ya tienes algunos co-generadores en su lugar para que todas las bibliotecas y aplicaciones se generen de manera uniforme como se esperaría. Entonces, no tienes que copiar y pegar, lo cual es propenso a errores, por supuesto, las bibliotecas existentes eliminan el código existente y luego continúan trabajando en eso. Pero incluso puedes no solo usar los generadores proporcionados por NX, sino adaptarlos realmente a tus propias necesidades. Puedes personalizarlos para que solo se genere lo que necesitas en tu espacio de trabajo actual. Fácilmente, eso también se puede activar desde Visual Studio Code. Y aquí, por ejemplo, puedes ver en este ejemplo de animación cómo configurar ese entorno de ejecución de tareas distribuidas para CI. Entonces, puedes generar fácilmente esa configuración de CI, que es muy útil. Y solo son un par de líneas de código, si lo miras al final. Entonces, este es un ejemplo de lo poderosos que pueden ser esos generadores sin que tengas que escribir largos documentos explicando cómo configurar esas cosas. De manera similar, por ejemplo, si quieres configurar una modificación de Webpack para React, NX ya viene con un complemento que puedes usar para configurar las aplicaciones principales y remotas. Y luego puedes usar eso para construir tus cosas existentes y continuar desarrollando sobre esos generadores.

Finalmente, también se previene las dependencias enredadas. Y esto es algo que la gente subestima mucho cuando comienza en monorepos. Porque comienzan muy emocionados al principio. Pero luego, si estás en medio de un año donde tienes varios equipos trabajando en un monorepo, las cosas pueden volverse desordenadas muy, muy rápido. Entonces, las personas importan de bibliotecas que no deberían importar, y tal vez incluso por accidente, porque vieron alguna biblioteca de utilidades genial y no se suponía que la usaran. Rápidamente, tu código puede volverse inmantenible. En NX, por ejemplo, como puedes ver aquí, puedes usar esas bibliotecas como dominios, ¿verdad? Donde puedes exponer claramente una API pública, para que otras personas de un dominio diferente puedan aprovechar esas funciones en su propio dominio. Ahora, ¿cómo puedes evitar que alguien importe una biblioteca diferente? En teoría, puedes hacerlo porque vives en el mismo monorepo. Ahora, en NX tenemos un sistema de etiquetado. Estas son simplemente cadenas. Entonces, puedes decir, por ejemplo, tengo una columna de alcance, algún nombre, que por ejemplo podría ser los dominios, y darle esas etiquetas a todas las aplicaciones y bibliotecas en un cierto dominio. Puedes agregar eso en tu configuración y todas esas bibliotecas lo recibirían.

Y luego también le das a esa API, por ejemplo, una etiqueta específica para marcarla como algo que puede ser consumido desde fuera del dominio. Y luego viene lo siguiente con una regla específica de ESLint. Entonces, en esta regla de ESLint aquí, por ejemplo, puedes ver cómo definimos una etiqueta de origen y decimos, OK, algo que se llama scope checkout, que es nuestro dominio de pago específico, solo puede depender de otras aplicaciones y bibliotecas que también vivan en ese scope checkout para que también tengan esa etiqueta o que tengan un API de scope. Porque, como, si hay un API de scope, hay algo que se puede usar explícitamente. Así que está bien. Y estas comprobaciones se pueden ejecutar en CI. Se ejecutan en tu editor. Así que ves inmediatamente si importas algo incorrecto y, por lo tanto, son muy, muy poderosas para mantener tu código mantenible. Y finalmente, migraciones automatizadas. Algo similar que mucha gente subestima, pero creo que escenarios como estos son muy comunes de usar. Entonces, los desarrolladores pueden plantear en la reunión que parece que necesitamos actualizar Webpack. Nuestra herramienta está desactualizada. Webpack ha estado funcionando durante un par de años. Definitivamente deberíamos actualizar. Además, React 18 ha salido. Así que tal vez deberíamos echarle un vistazo. Y lo que dice un gerente de producto, obviamente, es como, OK, entiendo que esto es importante. ¿Qué tan importante es? ¿Bloquea el envío de funciones? Y la mayoría de las veces no lo hace, ¿verdad? Es solo una tarea de mantenimiento que debe hacerse, ¿verdad? Pero obviamente, si esto lleva semanas y semanas, es muy difícil de llevar a cabo. Y así, la mayoría de las veces lo que sucede es como, sí, claro, los gerentes de producto no entienden. Pero, sí, hagámoslo para el tercer trimestre. Podemos reservar algo de tiempo, ¿verdad? Todos sabemos lo que sucede cuando llega el tercer trimestre. Toneladas de nuevas funciones, plazos muy urgentes. ¿Qué sucede con la herramienta? Simplemente se retrasa. Y así, una cosa que hacemos con NX y que implementamos con mucho éxito también en grandes empresas, es la migración de NX. Y así, lo que sucede aquí es que NX tiene una función incorporada que le permite definir scripts de migración que no solo migran tu configuración, sino también tu código fuente de una versión a la siguiente. Y así, si estás dentro de un espacio de trabajo NX existente y usas complementos de NX, NX sabe qué funciones estás usando, ¿verdad? Y así, cada vez que actualizas, simplemente ejecutas NX migrate, que analizará tu espacio de trabajo, actualizará tu package JSON, y luego generará un conjunto de scripts de migración que luego puedes inspeccionar y ejecutar en tu espacio de trabajo. Y así, esto transformará cosas como, por ejemplo, integraciones de Jest, actualizará tu Cypress a la última versión, actualizará React 18, cualquier versión de React a la que estés actualizando, y se asegurará de que el código siga siendo consistente ajustando también el código fuente potencial. Así que esta es una característica muy poderosa, algo que se subestima rápidamente. En general, me gustaría concluir, diciendo que una buena herramienta debería estar ahí para permitirte tomar las decisiones correctas, pero no solo ayudarte a comenzar rápidamente, lo cual es definitivamente importante para la adopción incremental, como hemos visto, sino que también debería ayudarte durante todo el ciclo de desarrollo. Y así, con NX, obtienes funciones que se pueden adoptar de forma incremental. Puedes personalizarlo según tus propios requisitos proporcionando, por ejemplo, generadores personalizados y especificando el diseño como deseas tenerlo. Y luego viene con todas esas características únicas, como la exploración visual de gráficos, cosas como las que hemos visto con las etiquetas de las reglas de lint de los clientes que te ayudan a mantener realmente tu espacio de trabajo y monorepo saludables a largo plazo. Definitivamente echa un vistazo a monorepo.tools y si quieres ponerte en contacto conmigo con preguntas, lo que sea, ponte en contacto con nuestra cuenta de Twitter de NX DevTools, a devrel en novel.io o en mi propia cuenta de Twitter, yuristr. Muchas gracias por ver. Adiós.