1001 Paquetes: Estrategias para gestionar Monorepos

Podrías pensar que esto se debe a que un monorepo es algo grande o porque es gris, también este es rojo, pero en realidad es por esta historia. La historia de seis personas ciegas que intentan descubrir qué es un elefante. Cada uno está tocando una parte y tratan de entender si es una lanza, una serpiente, un árbol o qué es esta cosa. Y a veces, cuando hablo con la gente sobre los monorepos, así es como me siento. Todos lo ven ligeramente diferente.

Mi nombre es Tali Barak, trabajo para Youbeak. Y hoy vamos a hablar sobre estrategias para gestionar monorepos y cómo abordamos eso. Se llama 1001 paquetes, pero no solo se trata de paquetes.

Entonces, empecemos, ¿qué es un monorepo? Y puedes ver todo tipo de definiciones. Esta es mi definición. Y para entender eso, necesitamos entender qué es un artefacto. Y en nuestro mundo, un artefacto, necesitas tener esta definición, una definición de diccionario. Un artefacto es un objeto hecho por un ser humano. Pero de hecho, cuando hablamos en el software, estamos hablando de cosas como paquetes, herramientas, sitios web o aplicaciones front-end, tal vez una aplicación móvil, un servidor back-end o parte de un servidor, que es un servicio, todos estos son artefactos.

Tradicionalmente, tendríamos un único repositorio. Y de cada repositorio en tu control de código fuente, crearías un único artefacto del anterior. En el mundo de los monorepos, todavía tenemos el mismo repositorio en el control de código fuente, pero en realidad estamos generando múltiples artefactos a partir del mismo repositorio. Pero si intentamos enfocarnos y esto es una conferencia de DevOps JS y estamos hablando del mundo de JavaScript, en realidad significa que en un repositorio tendríamos múltiples package JSON, porque lo que identifica en el mundo de JavaScript un artefacto es un archivo package JSON. Así es nuestro monorepo.

Pero hay una cosa más. Si tenemos un monorepo que se ve así, es probable que un package JSON, digamos dentro de foo, apunte a otro package JSON, habría una dependencia dentro de este monorepo. Así que esta es mi definición de un monorepo en el mundo de JavaScript. Un repositorio con múltiples package JSON conectados. Y de hecho, lo que tenemos en el monorepo es este tipo de gráfico de todos los paquetes internos y cómo están conectados. Y esto es crucial para entender todas las complejidades que luego encontramos con un monorepo. Esto se llama DAG, un Grafo Acíclico Directo. Eso es porque cada paquete apunta a otro. Y esperemos que no haya ciclos porque eso no es algo realmente bueno. Y estamos familiarizados con las herramientas incluso en esta conferencia.

Se discutieron algunas de ellas. Tenemos herramientas como LearnA y NX. Conocemos el gestor de paquetes como Yarn y PNPM y herramientas como TurboRepo. Y todas ellas son excelentes herramientas que nos ayudan a lidiar con los monorepos.

Pero antes de saltar y decidir qué herramienta es la mejor para nosotros, detengámonos. Y hablemos sobre las estrategias que queremos emplear en nuestro monorepo. Y soy un desarrollador, así que comienzo desde cero cuando hago contabilidad.

Y la primera estrategia se trata del alcance. ¿Qué queremos tener en nuestro monorepo? Los casos de uso comunes que vemos son cosas como herramientas de código abierto. Tenemos muchas de ellas. Hay realmente muchas herramientas que conocemos y con las que trabajamos que se construyen como un monorepo. Un microservicio puede ser también un gran caso de uso para un monorepo. O simplemente, como sabemos de la disciplina de Google y Facebook, colocar todo el código de la empresa en un solo lugar, pero eso no es un requisito para un monorepo.

Y ¿debería o no usar el monorepo? Hay dos excelentes artículos, uno a favor y otro en contra del monorepo. Lo bueno del monorepo es que es fácil compartir el código. Puedes hacer cambios que se reflejan en múltiples paquetes o proyectos a la vez. Puedes tener una publicación unificada y simplemente ser capaz de desplegar o publicar todos tus paquetes a la vez. Pero sabemos muy bien que no hay almuerzos gratis. Así que, con las cosas buenas vienen otras cosas que pueden desafiarnos. Para empezar, es un código base extenso, un código base extenso tiene muchos commits. Tal vez muchas personas estén trabajando en él. No siempre es fácil encontrar tu camino y ver lo que todos hicieron. Además, si necesitas alguna política de seguridad y no quieres que las personas accedan a ciertos tipos de repositorio, entonces el monorepo no es la buena herramienta para usar. Y también, el hecho de que todo el código se almacene en un solo lugar puede fomentar que las personas acoplen las diferentes partes del software más de lo que es aceptable. Y, por supuesto, también hay toda la configuración, también para el monorepo y cuando usas el repositorio, te encontrarás con algunos desafíos.

Pero digamos que decidiste que realmente quieres eso. Sí, voy a ir con el monorepo. Así que, hablemos ahora sobre cuáles son las estrategias que quieres tener cuando decides y cuáles son las formas en que debes tratar tu monorepo. Y comencemos con la primera estrategia, que es el lanzamiento. Tomemos dos casos de uso comunes en los que la gente usa monorepo. El primero es tener microservicios. Puedes tener múltiples servicios que se almacenan en tu repositorio y con algunos paquetes en los que esos servicios dependen.

Entonces, cuando despliegas, también necesitas instalar esos paquetes. Un caso algo similar, pero muy diferente, es cuando lo usas para una aplicación frontend, cuando tienes múltiples aplicaciones frontend en el mismo repositorio y un ejemplo muy clásico es si tienes la parte de cara al cliente en un lado y el panel interno en el mismo lado en el otro lado y quieres compartir mucho código entre ellos. En este caso, no necesitas publicar los paquetes porque las aplicaciones suelen estar agrupadas, simplemente necesitas agruparlas y luego lanzarlas.

Y luego la pregunta es, ¿cómo lo estoy gestionando? ¿Cuál es mi ritmo o cadencia de lanzamiento que voy a utilizar? Una forma de hacerlo es utilizar UNIFI, el término de aprendizaje para eso es fijo. Eso significa que cada vez que decido publicar o desplegar, publicaré todos los paquetes y todos los cambios y todo lo que se haya modificado con una sola versión. Solo tendré un registro de cambios con todos los cambios para las diferentes partes. Y si miras, por ejemplo, el repositorio de Angular, verás que eso es lo que hacen, independientemente de si el paquete ha cambiado o no, se incluirá en tu versión en el próximo lanzamiento. Otro enfoque es hacerlo independiente. Eso significa que cuando realizas un cambio en algún paquete o algún servicio o alguna aplicación, quieres desplegarlo y publicarlo independientemente de todos los demás paquetes, tendrá su propio registro de cambios, y también vemos eso en algunos ejemplos. Así que esto es lo primero que quieres entender cómo vas a trabajar con tu Monorepo.

La segunda estrategia, que está directamente relacionada con la primera, es cómo vas a construir tu Monorepo y tenemos en las herramientas que estamos utilizando dos categorías principales. La primera es en cada paquete, hago un script de construcción y simplemente ejecuto lo que quiera, puede ser una aplicación de frontend ejecutando Webpack, ejecutando TypeScript o lo que sea. Simplemente tengo eso como un script y puedo ejecutarlo. El otro enfoque, que creo que NX es probablemente un líder importante en este aspecto, es que en realidad tienes algún tipo de constructor o ejecutor que defines en la raíz de tu Monorepo y esos ejecutores son en realidad envoltorios que saben cómo lidiar con cada uno de los paquetes. Entonces tienes diferentes tipos de constructores, cada uno hace un trabajo específico. Pero ¿cómo decides qué construir cada vez? Digamos que hice un cambio en este paquete, ¿cómo decido qué quiero construir? Aquí hay algunas estrategias entre las que puedes elegir. La primera es la ingenua, no importa dónde haga cambios, simplemente construiré todo. Es fácil de entender, simplemente puedes reconstruir todo. El otro extremo es construir lo que puedas cambiar, publicarlo. Y luego, en algún otro paquete o aplicaciones en las que quieras incorporar esos cambios, simplemente lo instalas desde el registro de artefactos externo y luego publicas el otro.

Al trabajar en una CI, podemos realizar una construcción diferencial por ruta. Por ejemplo, GitHub Action tiene soporte para eso. Entonces puedes indicarles que construyan solo la ruta que cambiará. Pero el enfoque más sofisticado, y esto es de lo que todas las herramientas se enorgullecen, es utilizar una construcción de dependencias. Así sabes qué se ha cambiado al hacer una especie de Git desde el commit anterior. La herramienta conoce el gráfico de dependencias porque sabe cuáles son las relaciones dentro de tus paquetes. Y eso resultará en un gráfico de construcción que determinará qué debe construirse y en qué orden. Por ejemplo, así es como funciona Lerna. Puedes indicarles que construyan todo y todos los demás paquetes que dependen de él. NX y TurboRepo llevan esto un paso más allá. No solo conoces los cambios y el gráfico de dependencias, sino que también puedes almacenar en caché algunos de los artefactos intermedios. Y luego puedes tener un gráfico de construcción más pequeño, lo que significa construcciones más rápidas. Cuando la construcción está centralizada y hay una herramienta que controla todo y sabe exactamente qué debe instalarse, incluso puedes optimizar aún más. Esto es lo que hace TurboRepo, por ejemplo. Definirás algún tipo de pipelines y luego puede optimizar y ejecutar en paralelo y ver exactamente y minimizar lo que debe construirse en cada etapa.

La tercera estrategia, y nuevamente, estrechamente relacionada con la anterior, son los procesos de desarrollo. Y principalmente hablo de las pruebas y el linting, en este caso, las pruebas unitarias. Y veremos tres formas de hacerlo muy rápidamente. Una de ellas es realizar pruebas globales. Eso significa que solo tendré un comando en mi espacio de trabajo. Ejecutaré las pruebas para todos los archivos de especificación o prueba que pueda encontrar en mi repositorio cada vez. Ingenuo pero efectivo. La segunda opción es realizar una compilación local. Eso significa que cada paquete tendrá su propio script de prueba y puedes decidir en qué paquetes deseas ejecutarlo. Tal vez solo en algunos de ellos, o puedes hacerlo con reglas similares a la compilación. Y la tercera opción es centralizada, similar a la compilación. Tienes una configuración de espacio de trabajo para definir cómo se realizan las pruebas o el linting en cada uno de los paquetes, y puedes usarlo para controlar cuál usar. También me gustaría mencionar aquí sobre Just, que también es una configuración centralizada. Entonces puedes definir configuraciones específicas de Just para cada proyecto. Si tienes cosas que necesitan Babel, si necesitan diferentes configuraciones preestablecidas, puedes usar cada una de ellas.

La cuarta estrategia se trata de la vinculación. Y cuando digo vinculación, me refiero a cómo gestionamos la relación entre esos paquetes, todos los paquetes que existen en mi monorepo. Y esto no son paquetes externos de npm, solo los internos. Nuevamente, hay dos estrategias que son utilizadas por diferentes herramientas. La primera es que cada archivo package.json en cada uno de los paquetes especifica qué paquetes depende, incluidos los internos. Entonces, puedes tener, dirías, esta versión. Puedes cambiar la versión. Puedes tener una versión genérica. La otra opción, y esto es lo que hace Annex, es que puedes tener una relación implícita, que ocurre cuando haces la importación. Entonces, no necesitas especificar para cada uno qué paquetes dependen de él. Pero puedes importarlo y hay una relación allí. ¿Y cómo lo hacemos? Entonces, nuevamente, si lo llevas al extremo, casi como un poly repo, simplemente haces un cambio en el paquete. Lo compilas, lo publicas en el registro de artefactos, y luego lo instalas desde tu artefacto, desde tu registro privado o lo que sea, en el mismo repositorio. La otra opción, y esto es algo importante, es que los gestores de paquetes como npm y, en cierta medida, YARN, PNPM, también admiten esta parte de los monorepos. Esto es algo que saben hacer bastante bien.

En realidad, si utilizas Lerna y quieres usarlo con YARN, Lerna simplemente delegará la vinculación de paquetes a YARN. Y en este caso, especificamos cuáles son los paquetes, pero cuando hacemos la instalación o queremos vincularlos, instalará los módulos de nodo como si fueran paquetes normales, pero en realidad, se vinculará a la carpeta en el repositorio donde se encuentra el paquete.

Funciona perfectamente cuando trabajas con JavaScript básico. Es un poco menos ideal si trabajas con algo que requiere un proceso de compilación como TypeScript o módulos, y así sucesivamente, si necesitas Babel, entonces debes especificar la carpeta dist en lugar de build y asegurarte de que todo esté compilado correctamente.

Me gustaría mencionar nuevamente, una forma menos ortodoxa es utilizar la ruta de TypeScript. En lugar de especificar cuáles son los paquetes, puedes especificar las rutas de tus archivos TypeScript a los diferentes paquetes y simplemente usarlos. Pero podría ser una buena opción si lo usas para aplicaciones y estás construyendo múltiples aplicaciones. No es puramente un mono-repo, pero también es una forma posible.

Y la última estrategia se trata de la instalación. Y aquí me refiero a los módulos externos, a los módulos de NPM que deseas agregar en cada uno de los paquetes. Aquí hay algunas estrategias. Puedes especificar todos los paquetes que necesitas en la raíz de tu espacio de trabajo. Y esto solo es útil si estás construyendo una aplicación que tiene algún tipo de proceso de empaquetado. De lo contrario, obviamente no podrás instalar los otros como microservicios u otros paquetes porque las dependencias no existirán allí. Pero si estás trabajando con aplicaciones y utilizando un empaquetado, esta podría ser una buena opción. Tendrás menos problemas al intentar actualizar, menos incompatibilidades entre versiones. Y esto podría ser útil.

Pero si optas por el enfoque más tradicional, es decir, cada paquete tiene su propio package y tiene un conjunto de dependencias, entonces la primera opción es hacer una instalación local. Lo que significa que tienes las dependencias, y debajo de cada paquete tienes una carpeta de módulos de nodo y se instalará allí. Y luego te aseguras de que puedas tener diferentes versiones para diferentes paquetes. Esto lo hace muy autónomo.

Otra opción, y nuevamente, el gestor de paquetes lo admite, es hacer una elevación. Lo que significa que todo sigue definido a nivel de paquete, pero cuando se instala, se instala en un modelo de nodo único en la raíz, a menos que haya incompatibilidades de versiones. Y la razón por la que esto funciona es porque cuando Node busca un paquete, simplemente sube por el árbol e intenta encontrar el paquete en algún lugar más alto de la jerarquía. El riesgo aquí es que olvides agregar algún paquete en uno de tus paquetes y luego cuando lo implementes, no tengas ningún problema durante las pruebas o el desarrollo local porque está almacenado en algún lugar debido a otro paquete. Pero luego, cuando vayas a implementar solo este paquete en tu máquina de producción o en una máquina en pie, podrías obtener algunos errores y hay reglas de vinculación. Hay una regla de ESLint que verifica esto. Así que no tenemos que confiar en nuestra memoria y capacidad mental.

Entonces, para resumir, si queremos utilizar el monorepo, primero debemos entender qué es el alcance, qué queremos incluir en nuestro monorepo. No tiene que ser todo el código. Luego queremos definir cuáles son las estrategias que vamos a utilizar para la versión, la compilación, el proceso de desarrollo, cómo vamos a vincular los diferentes paquetes y cuál es nuestro método de instalación.

Y cuando decidimos cuáles son los procesos adecuados para nuestra organización, podemos verificar qué capacidades ofrecen las herramientas y cuál es la herramienta adecuada para nosotros. Y eso es todo. Muchas gracias por eso. Y estos son mis datos de contacto.

¡Hola, Tally, ¿cómo estás? Hola, estoy bien. ¿Y tú? Genial, genial. Realmente energizado después de tu charla, como realmente estas notas que tomé, y estoy seguro de que la audiencia también tomó muchas notas hoy.

Entonces... Bueno, hiciste la pregunta a la audiencia, ¿utilizan un plan para utilizar una organización de monorepo? Sí, las aplicaciones frontend ganan con un 48% y luego un 32% de las personas lo utilizan tanto para backend como frontend. Sí, esta fue una pregunta de respuestas múltiples, por lo que no suma el 100%, en realidad es más de eso. Y es más o menos lo que esperaba, tengo que decirlo. Esperaba que los monorepos fueran más populares para las aplicaciones frontend que para las de backend. Y supongo que también tiene que ver con la popularidad de los microservicios en general. Y lo sorprendente es que el 32%, aproximadamente un tercio de la audiencia, lo utiliza tanto para backend como frontend. Y creo que eso es un desafío bastante interesante para las personas que gestionan un monorepo de ese tipo.

Sí, definitivamente. Es bastante interesante. Y también imagino que frontend sería el número más alto para los monorepos. Sí. Eso es genial. Así que hagamos algunas preguntas. Veo una pregunta que es si hay reemplazos de gestores de paquetes para herramientas de monorepo como Lona y NX. Sí, quiero decir, esto probablemente se mencione en algunas de las otras herramientas. Y tuvimos las charlas sobre PMPM y NPM. Y definitivamente las herramientas son importantes. Y el avance que han tenido en el manejo de monorepos es lo que realmente las habilita. Es genial querer tener un monorepo, pero si no tienes las herramientas adecuadas. Las razones podrían ser, a menos que quieras crear todo tipo de scripts. Así que ellas se encargan de parte de eso. Principalmente, la vinculación e instalación de paquetes.

Pero además de eso, necesitas las herramientas reales para la construcción y a veces para la publicación, como Lerna. Por lo tanto, hay mucha funcionalidad y los gestores de paquetes no cubren todo. Solo diría que un subconjunto. Sí, entendido. Entonces, Mathias Gheno pregunta, ¿cuál es tu opinión sobre tener varios equipos en un monorepo? Bueno, creo que el término 'equipos' es una descripción muy inexacta. Porque no tienes un monorepo para una sola persona. Entonces, una vez que tienes varias personas, depende. Definitivamente puede funcionar. Creo que es un desafío. Creo que todo el monorepo es una decisión que debe tomarse y considerarse seriamente. Y tener varios equipos significa muchos commits, muchas solicitudes de extracción. Necesitas gestionarlos adecuadamente. Incluso si no hablo de las herramientas en sí, significa que hay mucho ruido y a veces, debido a que somos humanos y tenemos una cantidad limitada de atención que podemos dar a algo, si vemos todo ese código a nuestro alrededor, puede volverse confuso. No estoy diciendo que no funcione, pero solo piénsalo. ¿Realmente quieres todo ese ruido en un solo lugar? ¿Realmente quieres ejecutar la construcción cada vez que alguien de un equipo completamente diferente hace un push? No lo sé. Esa es una consideración, esa es una estrategia. Sí, es subjetivo, depende de tu escenario y supongo que sí.

De acuerdo, ¿crees que se pueden crear monorepos considerando los dominios de la empresa, como un dominio impulsado por microservicios? ¿Se pueden crear considerando el dominio? Sí, definitivamente. Esperaría tener diferentes dominios en un monorepo y luego puedes publicarlo para micro frontends. No creo que haya mencionado mucho los micro frontends, pero sí, puedes incluir en un monorepo una aplicación que sea como una construcción de micro frontend o mis microservicios. Absolutamente. Eso es realmente, creo, donde el monorepo brillará. Definitivamente seguiría ese enfoque. Genial. Florian Rappel pregunta, a menudo tengo dificultades para configurar las pruebas, simplemente ejecutar todo y ejecutar las pruebas individualmente. Veo la diferencia principalmente en si tendría sentido tener diferentes ejecutores de pruebas o diferentes entornos de pruebas para los paquetes individuales. ¿Qué opinas? Tengo muchas opiniones sobre cada tema. No, pero creo que llevaré la pregunta un paso más allá. ¿Cómo lidias con diferentes herramientas, no solo ejecutores de pruebas, qué pasa si usas Linter o incluso paquetes, pero el ejecutor de pruebas definitivamente es uno.

En un entorno de monorepo, no todas las herramientas funcionan bien. No quiero mencionar, pero me he encontrado con herramientas que son muy problemáticas para trabajar en un monorepo. A veces, trabajar en una ruta que no es la raíz no es posible y luego más adelante pueden agregar soporte. ¿Tendría sentido tener diferentes ejecutores de pruebas? Sí, si tienes algún proyecto heredado, pero creo que idealmente pones todas las cosas en el monorepo, tal vez sea un buen momento para unificar y trabajar en un entorno de herramientas unificado, que es donde un monorepo realmente puede ayudarte. Gracias. Entonces, la siguiente pregunta, Sebi pregunta, ¿cómo estructurarías monorepos con Deno ya que no hay un gestor de paquetes y, por lo tanto, no hay paquetes reales, solo archivos y carpetas? Tal vez esto sea el futuro cuando no tengamos que lidiar con todos los problemas, pero incluso si pones una aplicación de Deno y solo tengo un poco de conocimiento sobre Deno para ser justos, aún necesitas ejecutar pruebas, probablemente estás analizando tu código, quiero decir, los desarrolladores de Deno probablemente quieran hacer eso. Entonces todavía necesitas algunas de las herramientas. Y sí, puedes saltarte el horror de los paquetes, pero aún tienes algunas otras cosas. Y puedo imaginar también, no he trabajado en ese entorno, que en algún momento querrás compartir algunos archivos. Y tienes tus archivos de mapeo de Deno de los paquetes a la implementación real. Entonces es posible que desees compartirlos entre tus microservicios y así sucesivamente. Pero creo que esto es algo que será muy interesante ver cómo evoluciona cuando no tengamos todos los problemas de los paquetes. Eso es interesante. Entonces, solo para expandir un poco, porque a lo largo de esta conferencia, vimos diferentes herramientas y monorepos, hubo varias charlas. Entonces, solo quería preguntar, ¿cómo crees que será el futuro de los monorepos? ¿Qué veo? Entonces, en realidad, el ejemplo de Deno es bueno. Definitivamente, a corto plazo, en los próximos años, veremos cada vez más herramientas que respaldan los monorepos. Herramientas que no lo hacían, y ya vemos muchas herramientas que entran en juego. Ahora tienes Tuberipo como un nuevo jugador. Leona, estuvimos tan apurados en algún momento, así que vemos herramientas y supongo que esto no es el final. Probablemente habrá más herramientas al respecto. Y en algún momento, tal vez podamos estandarizar la forma de trabajar con monorepos y no tengamos que reinventar todo cada vez que construimos un nuevo proyecto. Pero creo que será un futuro muy interesante y agradable, si me preguntas. Es interesante, sí, interesante sin duda. Realmente espero buenos tiempos por delante, diría yo. Buenos tiempos se acercan. Sí, genial. Entonces, solo me gustaría hacer una pregunta no técnica, porque realmente estoy asombrado por ti y tu experiencia. Entonces me gustaría saber un poco sobre tu trayectoria, cómo comenzaste y todo con este desarrollo web.

Wow. Sí, comencé a programar a los 13 años, y eso fue en 1983. Así que todos están invitados a hacer el cálculo. Terminas con 51. Obtuve mi primera computadora. En realidad, estaba viendo a alguien programar y supe que esto es lo que quería hacer. Es donde tenemos un servicio militar obligatorio. Así que cuando me uní al Ejército, en realidad estaba en una unidad de computadoras y luego en la universidad. Y desde entonces, durante más de 30 años, esto es lo que hago. Me encanta. Estuve alejado de la programación por un tiempo, pero siempre haciendo cosas relacionadas en esta área. Y hace casi ocho o nueve años, volví a todo este mundo de JavaScript. Y realmente lo disfruto. Bueno, lo que realmente me gusta es que tengo la experiencia de cómo trabajar con sistemas grandes. Y esto es lo que trato de aportar cuando hablo con la gente, mis charlas no se tratan solo de los aspectos técnicos, sino de cómo combinar esa tecnología con las personas debido a toda esta experiencia que tengo. Es increíble. Realmente, tu trayectoria es inspiradora. Estoy totalmente asombrado por ti. Diría que estoy muy feliz de recibirte hoy. Muchas gracias por esta increíble charla y todas estas respuestas y discusiones interesantes. Fue un placer tenerte aquí hoy con nosotros. Igualmente. Gracias.