Gestión de proyectos Node.js a gran escala con Monorepos

Hola a todos. Mi nombre es Fortune Ikechi. Soy un ingeniero de software y escritor técnico. Cuando esto fue creado, era un ingeniero desarrollador en Storyblok. Ya no lo soy. Puedes encontrarme en Twitter como underscore, en codoc underscore. Y hoy hablaré, daré una charla relámpago sobre cómo gestionar proyectos de Node.js a gran escala con monorepos.

Y sí, voy a mirar esta tabla de contenidos. El número uno es Introducción a los Monorepos y su papel en el desarrollo de Node.js. Correcto. También veremos las mejores prácticas para organizar tu código. También hablaré sobre las estrategias de escalabilidad para aplicaciones de Node.js, y terminaré con herramientas y flujos de trabajo de colaboración que puedes usar para aplicaciones de Node.js en monorepos.

Ahora, empecemos. Así que el número uno es la Introducción a los Monorepos y su papel en el desarrollo de Node.js. Ahora, antes de empezar, tengo que mencionar qué es un monorepo, ¿verdad? Un monorepo en su totalidad se llama en realidad repositorio monolítico o monolithic repository. Es una estrategia de desarrollo en la que tienes muchos proyectos y almacenas tantos proyectos en un repositorio, actuando como una única fuente de verdad para múltiples proyectos. Así que piénsalo como cuando tienes tus aplicaciones monolíticas, donde tienes todo unido en un proyecto en particular sin separar preocupaciones y todas esas cosas. Básicamente, el frontend, backend están todos en un mismo lugar. Pero en este caso, un repositorio monolítico o un monorepo es básicamente donde tienes tres, cuatro proyectos en un solo proyecto, y eso se convierte en la fuente de verdad para todo el proyecto.

Ahora, lo que los monorepos ayudan a hacer es facilitar el intercambio de código, ¿verdad? Porque con esto, puedes compartir código entre los diferentes proyectos, ¿verdad? Y reutilizar los diferentes componentes de modelos o paquetes en esos proyectos. Y lo segundo que hace es simplificar la gestión de dependencias. Y aquí es donde intentas tener múltiples dependencias, ¿verdad? Probablemente una dependencia de carpeta o archivo o JSON que maneje todos los proyectos enteros. Y lo último que hacen los monorepos es mejorar la colaboración entre diferentes equipos. Ahora, debido a que los monorepos son diferentes proyectos en una configuración particular, puedes tener a todos esos proyectos, ingenieros o personas que trabajan en esos proyectos, o los equipos, nuevamente colaborando para usar probablemente diferentes modelos o paquetes en todos los proyectos.

Ahora, voy a hablar de los beneficios de los Monorepos, y aquí he enumerado la simplificación de la gestión de dependencias. Ya expliqué que puedes tener, nuevamente, un paquete centralizado para tus dependencias. Y esto es realmente, realmente esencial en el entorno de Node.js porque Node.js trabaja con la idea de modelos compartidos, ¿verdad? Y ahora, cuando tienes todas estas dependencias, probablemente desde un solo archivo, puedes compartirlas entre los diferentes modelos de tu proyecto de Node.js en un Monorepo. Y también puedes importar todas ellas desde un solo archivo, básicamente. Y lo siguiente que mencioné es que se unifican los scripts lineales. Ahora, con los Monorepos, puedes tener un proceso de construcción, prueba e implementación coherente en todos tus proyectos. Y esto se debe a que puedes tener básicamente un solo archivo, probablemente un solo script allí, como un archivo JSON, package.json, que maneje todos tus scripts, tus herramientas, tus pruebas para todos los proyectos. Y con esto, tus ingenieros y equipos pueden construir de manera consistente siguiendo ese formato de prueba en particular o ese formato de construcción o proceso de implementación.

El siguiente beneficio de los Monorepos es que ayudan a mejorar la reutilización del código. Esto se debe a que es muy fácil compartir código entre los proyectos. Voy a hablar más sobre esto más adelante o dedicar más tiempo a esto más adelante debido a la charla y luego lo veremos. Y añadí aquí que esto reduce la redundancia y fomenta la consistencia. Cuando tienes básicamente un solo código que usas en múltiples proyectos, hay una versión consistente de ese código que se está utilizando, ¿verdad? Es básicamente el mismo código reutilizado en múltiples lugares. Y luego tú y tu equipo pueden estar seguros de la consistencia en múltiples códigos que se utilizan en múltiples proyectos o un solo código que se utiliza en múltiples proyectos. Lo siguiente que mencioné aquí es la colaboración en equipo. Ahora, al centralizar tu base de código, los Monorepos no solo simplifican la gestión de dependencias, sino que también ayudan a colaborar mejor con tu entorno o tu equipo. Ahora, debido a esto, los equipos pueden trabajar más estrechamente con modelos interconectados, ¿verdad? Esto puede ayudar al tiempo de desarrollo porque ahora estás seguro de lo que obtienes de cada modelo. Y luego no tienes que preocuparte por tal vez algunos casos especiales o efectos secundarios de ciertos modelos que ocurren entre los proyectos. Ahora, quería mencionar los Monorepos de Node.js y los Monorepos en el desarrollo de Node.js. Ahora, escuché que Node.js sigue un enfoque modular, ¿verdad? Y esto complementa cómo funcionan básicamente los Monorepos. Y esto facilita mucho la gestión de interdependencias entre modelos porque, nuevamente, tienes una sola dependencia que funciona en los diferentes modelos de tu aplicación. También añadí aquí la compatibilidad con la arquitectura modular, ¿verdad? Y con Node.js, Node.js trabaja con paquetes o modelos muy pequeños y reutilizables que puedes usar en proyectos. Y esto funciona de nuevo con la forma en que funcionan los Monorepos, porque ahora en este caso, puedes tener una carpeta llamada utils y esa carpeta es como todos los paquetes para la autenticación o todos los paquetes para los inicios de sesión de producción y todo eso. Y luego puedes reutilizar este módulo particular en todos tus proyectos, ¿verdad? En diferentes carpetas en ese Monorepo en particular. Y ahora voy a mencionar la refactorización entre proyectos, ¿verdad? Ahora, con esto, no tienes que tener miedo de hacer cambios y luego preocuparte de cómo afecta a todo el proyecto, porque todos tus cambios básicamente funcionan en un solo lugar. Y las dependencias son nuevamente una sola dependencia.

Así que puedes hacer las actualizaciones, el código gráfico sin preocuparte por un efecto secundario o probablemente el cambio en cambios que rompen y todas esas cosas. Porque, nuevamente, estos son solo modelos singulares que afectan a múltiples proyectos. Y puedes estar seguro de cómo funcionan todos porque está en una caja y se colabora con un enfoque de monorepo. Y se añadieron configuraciones compartidas.

Creo que vemos esto todos los días con el linting, el formateo y la configuración de pruebas en diferentes proyectos dentro del monorepo. Ahora, con esta consistencia, ¿verdad? Puedes estar seguro de que quizás un solo caso de prueba funciona en todos los proyectos o tu equipo construyendo el proyecto en sincronía con ese desarrollo impulsado por pruebas o ese caso de prueba en particular. Y esto puede hacer que sea realmente más fácil cómo evolucionas nuevos paquetes porque solo tienes que asegurarte de que funcione en todos los proyectos y luego se puedan usar de manera segura en todos los proyectos de tus monorepos.

Añadí algunos soportes de herramientas para Node.js monorepos. Y el primero en el que quería fijarme fue Nix. Creo que lo llaman Nix. Algunas personas lo llaman Nix, pero para mí es Nix. Entonces, Nix es básicamente una herramienta de desarrollo personalizada que facilita seguir un enfoque de monorepo. Y lo que Nix hace bien es que simula tu flujo de trabajo y lo hace muy eficiente para construir aplicaciones de Node.js. Ahora, Nix hace esto al proporcionar soporte semántico y una CLI que facilita automatizar algunas tareas repetitivas, ¿verdad? Y nuevamente, esto mejora tu enfoque de Node.js. Pero, ¿qué soporte proporciona? Como esos JS, Cypress, ES links. Y esto ayuda a tu código con una calidad y consistencia altas. Pero, ¿cómo ayuda esto realmente a tu monorepo? Ahora, porque estás seguro de que puedes escribir un solo caso de prueba que podría afectar a todos los proyectos, puedes estar seguro de no tener que preocuparte por escribir múltiples proyectos o múltiples casos de prueba para múltiples proyectos, o incluso tener que definir diferentes estrategias de linting para diferentes proyectos en tu monorepo. Y esto es una de las cosas que Nix te ayuda a hacer. También añadí los Yarn Workspaces. Y ahora, lo que los Yarn Workspaces hacen realmente bien es que te permiten básicamente tener un solo archivo raíz de paquete JSON. Y esto ayuda con la instalación de dependencias, ¿verdad? Solo tienes que instalar una sola dependencia que funcionará en todos mis proyectos en todo momento. Y luego también puedes vincular las diferentes dependencias a un solo archivo de paquete de JSON. Y eso es en caso de que tengas diferentes archivos JSON que puedas usar. Y nuevamente, otra cosa que ayuda a hacer los Yarn Workspaces es que en realidad te ayuda a, con un solo comando, trabajar con todos los paquetes de JSON en tus diferentes proyectos. Esto se debe a que todos los paquetes están alojados. Hay enlaces a un archivo principal o raíz en particular. Y eso te ayuda con, nuevamente, tu monorepo, ¿verdad? Y con esto, simplemente reduce la cantidad de espacio que tu computadora utiliza cuando estás trabajando con Yarn Workspaces y el enfoque de monorepo.

Lo último que quería mencionar, creo, sí, lo último que quería mencionar es el NPM Workspaces. Y creo que muchos de ustedes ya lo usan porque lo veo en varios paquetes de código abierto. Y lo que hace esto es que ofrece un soporte nativo para monorepos, ¿verdad? Te permite configurar la instalación automática para vincular tus diferentes paquetes dentro del

Lo siguiente en lo que queremos centrarnos son las mejores prácticas para organizar el código en el monorepo. Ahora, agregué modelos detallados. Y este es un consejo de que debes descomponer tu base de código en modelos pequeños y razonables que realicen una sola función o característica. Por ejemplo, aquí tengo en esta imagen de código o bloque de código, un registro que básicamente registra información y errores, ¿verdad? Y luego puedes importarlo en todas las aplicaciones múltiples en tu monorepo. También tengo aquí un validador, que nuevamente, es una expresión regular para tu correo electrónico o tu número de teléfono. Y nuevamente, esto se puede usar en todos los archivos múltiples o los paquetes múltiples o modelos o proyectos que tienes en tu monorepo. Y esa es la excelencia de organizar el código en un monorepo de Node.js. También agregué aquí una estructura de directorios, que te permite crear una estructura de directorios consistente, ¿verdad? Que básicamente refleja cómo es tu aplicación y la relación entre tus paquetes o tus aplicaciones o proyectos. Aquí en el código, tenemos una carpeta de paquetes y en esa carpeta en particular, tenemos autenticación, que tiene una fuente y un package.json. Y luego, en esa carpeta nuevamente, tenemos la gestión de usuarios, que maneja todas las características de gestión de usuarios en este proyecto en particular. También tenemos el servicio de imágenes, que maneja todo el servicio de imágenes de los usuarios en este proyecto en particular o monorepo. Y esta es una excelente manera de organizar tus directorios, ¿verdad? Porque con esto, puedes vincular los diferentes package.json o incluso diferentes aplicaciones entre sí. Por ejemplo, puedo usar la autenticación para trabajar con la gestión de usuarios. Puedo usar la autenticación para trabajar con el servicio de imágenes. Agregué aquí utilidades y bibliotecas compartidas. Y ahora, esto es en colaboración con nuestro primer punto, ¿verdad? Que es una biblioteca o enfoque modular y detallado. Y ahora, con esto, básicamente puedes crear paquetes de tamaño pequeño que se pueden importar y usar en diferentes paquetes, protocolos o incluso proyectos. Ahora, lo siguiente en nuestra diapositiva son las estrategias de escalabilidad para aplicaciones de Node.js, ¿verdad? Básicamente, ¿cuáles son las estrategias que vas a utilizar para implementar un repo de Node.js y asegurarte de que la aplicación también sea escalable, mejore su rendimiento como debería y sea sostenible? Y la primera es la duplicación de dependencias. Ahora, tenemos paquetes y herramientas como npm-dedu o la Duplicación Automática de Yarn, que nuevamente te ayudan a reducir el tamaño de tus modelos de Node al redimensionar y aplanar tus dependencias. Y ahora, lo que esto hace es que te ayuda básicamente a acelerar tu tiempo de instalación y reducir el uso de tu disco. Porque lo que hace Node.js es que toma cuatro paquetes duplicados y los elimina, permitiéndote usar solo un paquete único cuando sea necesario, ¿verdad? Y esto puede reducir seriamente el tamaño de tus modelos de Node. Lo siguiente que agregué aquí es la instalación selectiva de dependencias. Básicamente, cuando usas Espacios de Trabajo de Yarn o Espacios de Trabajo de npm, puedes instalar solo una dependencia a nivel de raíz, ¿verdad? En lugar de duplicarlas en múltiples paquetes, como por ejemplo, si quieres usar bcrypt o cualquier otro paquete, ¿verdad? Básicamente, puedes tener uno de estos dos en tu paquete de Espacios de Trabajo de Yarn o npm en tu nivel raíz, y luego usarlo en todos los diferentes paquetes, modelos y proyectos en este

El número tres es cómo optimizar el rendimiento de un monorepo de Node.js. Y aquí agregué el perfilado y el monitoreo, ¿verdad? Básicamente, puedes perfilar regularmente tus aplicaciones, utilizar herramientas como NodeSpec o Chrome DevTools o incluso utilizar soluciones de terceros como New Relic. Soy un gran fan de New Relic. También puedes implementar estrategias de almacenamiento en caché para los datos de acceso frecuente. Esto puede ser en memoria o utilizando sistemas de almacenamiento en caché distribuidos como Redix. Creo que muchos de nosotros ya hemos utilizado Redix y New Relic. Si no lo has hecho, puedes consultar su documentación. Son realmente excelentes.

Ahora, ¿cómo colaboras con otros desarrolladores en un monorepo de Node.js? ¿Cuáles son las herramientas y flujos de trabajo que pueden ayudarnos a colaborar mejor? Lo primero que mencioné aquí es un modelo de ramificación. Y mencioné que debes adoptar una estrategia de ramificación, como GitFlow o desarrollo basado en tronco, para gestionar el desarrollo y las versiones de manera estructurada. Básicamente, dije que el desarrollo basado en tronco puede ayudar a minimizar las solicitudes principales y facilitar la integración continua. Pero lo siguiente que hace es ayudarte a realizar commits pequeños, ¿verdad? Con un monorepo de Node.js, se recomienda hacer solo commits pequeños en tu repositorio de GitHub para un cambio o una característica en particular. Y esto te ayuda a dar claridad a otros desarrolladores sobre qué hace esa característica en particular y por qué es necesaria. También he mencionado las pruebas automatizadas. Tenemos herramientas como Jenkins, GitHub Actions y GitLab CI para ejecutar pruebas automatizadas en las solicitudes de extracción. Y lo que hace es ayudar a los expertos tempranos que están trabajando en un repositorio en particular a realizar cambios en ese repositorio o incluso verificar los cambios que otras personas han realizado en ese repositorio. Creo que esta es una excelente manera que veo que muchas personas hacen en el ámbito del código abierto para ayudar con las pruebas automatizadas, ¿verdad? El siguiente es las pruebas paralelas, y eso sería crear un pipeline de CI/CD para ejecutar pruebas en paralelo o tiempo para monorepos. Ahora tenemos herramientas como GitHub Actions y GitLab, que nuevamente aprenden las mismas funcionalidades para ayudar en un estado paralelo en varios ejecutores, ¿verdad? Y no quiero entrar en esto demasiado, pero básicamente con GitHub Actions, puedes ejecutar pruebas de manera paralela en los diferentes ejecutores que tienes en tu aplicación. Ahora, ¿cuáles son los procesos de revisión de código que puedes utilizar en monorepos? Uno es la guía de solicitudes de extracción. Y dije que puedes establecer pautas claras para crear solicitudes de extracción, incluyendo convenciones de nomenclatura, información opcional requerida en la descripción. Básicamente, esto te permite solucionar problemas no relacionados o documentar tus solicitudes de extracción. Y esto también puede ayudarte a crear una nueva guía para esas solicitudes de extracción. También he mencionado las verificaciones automáticas de calidad de código. Ahora tenemos herramientas como Sonocue, ESLink y CodeCov, que te ayudan a realizar verificaciones de calidad de código y cobertura inversa en las solicitudes de extracción a través de pipelines de CI/CD. Creo que también veo esto en GitHub.

Ahora, ¿qué es DOS que te ayuda, simplemente monitorea tu aplicación para cuando haya solicitudes de extracción, ¿verdad? También verifica la calidad del código que recibes en esa solicitud de extracción. También tenemos asignaciones de revisión de código. Ahora, con herramientas como GitHub Codonas o GitLab Approval Rules, puedes asignar revisores a las solicitudes de extracción en función del área de la base de código con la que se sientan más cómodos o en la que son expertos. Aquí agregué que este es un ejemplo de un archivo Codonas. Y lo que hace este archivo es que la carpeta Auth en el directorio de paquetes se asigna al equipo de Auth, mientras que la API se asigna al equipo de API y la UI se asigna al equipo de UI. Y esa es una excelente manera de tener procesos de revisión de código en un monorepo.

Y ahora, para la conclusión, ya expliqué cómo los monorepos agilizan el desarrollo de Node.js al ofrecer un flujo de trabajo unificado para gestionar tu proyecto. También vimos los beneficios de la modularización. Mencioné la estructura de directorios. También mencioné la gestión de dependencias, ¿verdad? También mencioné una base de código manejable. Para hacer referencia, mencioné estrategias de escalabilidad y cómo debes tener una compilación eficiente y optimización de rendimiento para tu proceso de código. Terminé esta charla hablando sobre cómo puedes utilizar Git o el flujo basado en tronco para almacenar tus contratos de origen. También terminé hablando sobre procesos efectivos de revisión de código. Y eso es excelente porque todos lo hacemos, incluso con o sin monorepos, no solo en el ecosistema de Node.js, sino también en otras aplicaciones que construimos.

Nuevamente, mi nombre es Fortune Iketchi. Soy ingeniero de software y hasta hace poco fui ingeniero de DevRel en Storyblok. Puedes encontrarme en Twitter en CodeDog underscore. Muchas gracias.