1001 Paquetes: Estrategias para gestionar Monorepos

Rate this content
Bookmark

Cuando trabajamos con un monorepo, nos enfrentamos a múltiples desafíos: instalación de paquetes, vinculación de paquetes, procesos de desarrollo (compilación, linting, pruebas) y procesos de implementación. Estos desafíos varían según el tipo de artefactos en nuestro monorepo (microservicios, aplicaciones de frontend, paquetes, etc.). Exploraremos diferentes enfoques y herramientas para monorepos y sus ventajas y desventajas.

24 min
25 Mar, 2022

Video Summary and Transcription

Esta charla analiza estrategias para gestionar monorepos, incluyendo estrategias de lanzamiento, estrategias de construcción, procesos de desarrollo y vinculación de paquetes. El orador destaca los desafíos y complejidades de los monorepos, como los grandes conjuntos de código y el posible acoplamiento de las partes del software. También menciona la importancia de herramientas adecuadas para una gestión exitosa de monorepos y el potencial de estandarización en el futuro. Además, el orador comparte su trayectoria personal en la programación, comenzando desde temprana edad y expresando su amor por el campo.

Available in English

1. Introducción a los Monorepos

Short description:

Cuando pienso en un monorepo, pienso en un elefante. Mi nombre es Tali Barak, trabajo para Youbeak. Hoy vamos a hablar sobre estrategias para gestionar monorepos y cómo abordamos eso. En el mundo de los monorepos, todavía tenemos un único repositorio en el control de código fuente, pero generamos múltiples artefactos a partir del mismo repositorio. En el mundo de JavaScript, un monorepo es un repositorio con múltiples package JSON conectados. Es crucial entender las complejidades que encontramos con un monorepo, que es un Grafo Acíclico Directo.

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.

2. Estrategias para gestionar Monorepos

Short description:

Algunas herramientas como LearnA, NX, Yarn, PNPM y TurboRepo nos ayudan a lidiar con los monorepos. Antes de decidir qué herramienta utilizar, vamos a discutir las estrategias a emplear en nuestro monorepo. Los casos de uso comunes incluyen herramientas de código abierto, microservicios y sistemas de diseño. Los monorepos ofrecen un fácil intercambio de código, commits atómicos, publicación y despliegue unificados. Sin embargo, también presentan desafíos como un código base extenso, dificultad para rastrear cambios, preocupaciones de seguridad y posible acoplamiento de partes del software. A pesar de estos desafíos, exploremos las estrategias para tratar un monorepo, comenzando con la estrategia de lanzamiento y su aplicación en microservicios.

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.

3. Gestión de Lanzamientos en Monorepos

Short description:

Cuando tienes múltiples aplicaciones frontend en el mismo repositorio y quieres compartir código entre ellas, puedes agrupar las aplicaciones en lugar de publicar paquetes. Puedes gestionar el ritmo de lanzamiento utilizando un enfoque fijo, donde todos los paquetes y cambios se publican juntos, o un enfoque independiente, donde cada paquete tiene su propio registro de cambios.

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.

4. Estrategias de Construcción y Gráfico de Dependencias

Short description:

La segunda estrategia para construir un Monorepo involucra dos categorías principales de herramientas: scripts de construcción individuales en cada paquete o el uso de constructores/ejecutores definidos en la raíz del Monorepo. Se pueden emplear diferentes estrategias para determinar qué construir, desde construir todo hasta utilizar una construcción de dependencias que analiza los cambios y el gráfico de dependencias. Herramientas como Lerna, NX y TurboRepo optimizan el proceso de construcción y almacenan en caché los artefactos intermedios para construcciones más rápidas.

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.

5. Estrategias para Construir Monorepos

Short description:

Si estamos trabajando en una CI, podemos realizar una construcción diferencial por ruta. El enfoque más sofisticado es utilizar una construcción de dependencias, que analiza los cambios y el gráfico de dependencias para determinar qué debe construirse y en qué orden. Herramientas como Lerna, NX y TurboRepo optimizan el proceso de construcción y almacenan en caché artefactos intermedios para construcciones más rápidas. TurboRepo, en particular, centraliza la construcción y utiliza pipelines para optimizar y minimizar aún más el proceso de construcción en cada etapa.

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.

6. Procesos de Desarrollo y Vinculación de Paquetes

Short description:

La tercera estrategia se trata de los procesos de desarrollo, específicamente las pruebas y el linting. Hay tres formas de abordar esto: pruebas globales, compilación local y configuración centralizada. En cuanto a la vinculación de paquetes dentro de un monorepo, hay dos estrategias: dependencias en el archivo package.json y relaciones implícitas. Los gestores de paquetes como npm, YARN y PNPM también admiten este aspecto de los monorepos.

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.

7. Estrategias para Monorepos: Vinculación e Instalación

Short description:

Si utilizas Lerna con YARN, Lerna delega la vinculación de paquetes a YARN. Para TypeScript y módulos, especifica la carpeta dist para compilaciones correctas. Otra opción es utilizar rutas de TypeScript para construir múltiples aplicaciones. Para la instalación, puedes especificar todos los paquetes en la raíz del espacio de trabajo para facilitar las actualizaciones y reducir las incompatibilidades de versiones. Alternativamente, cada paquete puede tener sus propias dependencias con una instalación local o elevación para un modelo de nodo único en la raíz. Recuerda verificar las dependencias para evitar errores durante la implementación.

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.

8. Procesos y Herramientas para Monorepos

Short description:

Cuando decidimos qué procesos utilizar, debemos considerar las capacidades de las herramientas disponibles. Gracias por su atención. La audiencia mostró preferencia por utilizar monorepos en aplicaciones frontend, seguido de utilizarlos tanto para backend como frontend. Esto se alinea con la popularidad de los microservicios. Gestionar un monorepo para backend y frontend plantea un desafío interesante. Se planteó la pregunta sobre reemplazos de gestores de paquetes para herramientas de monorepo como Lona y NX, destacando la importancia de contar con herramientas adecuadas para una gestión exitosa del monorepo.

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.

9. Gestión de múltiples equipos y dominios en Monorepos

Short description:

En un monorepo, se necesitan herramientas adicionales para la construcción y publicación, ya que los gestores de paquetes no cubren todas las funcionalidades. Varios equipos en un monorepo pueden funcionar, pero requiere una gestión adecuada de los commits y las solicitudes de extracción. Hay que tener en cuenta el ruido y el posible desorden de tener todo el código en un solo lugar. Los monorepos se pueden crear en función de diferentes dominios, como los dominios impulsados por microservicios. Sin embargo, gestionar diferentes herramientas, incluidos los ejecutores de pruebas y los frameworks, puede agregar complejidad a un entorno de monorepo.

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.

10. Complejidades y el Futuro de los Monorepos

Short description:

En un entorno de monorepo, no todas las herramientas funcionan bien. Puede ser necesario utilizar diferentes ejecutores de pruebas, pero idealmente, poner todo en un entorno de herramientas unificado puede beneficiar a un monorepo. Al estructurar monorepos con Deno, aunque no hay un gestor de paquetes, sigue siendo necesario contar con herramientas para ejecutar pruebas, analizar el código y compartir archivos. El futuro de los monorepos parece prometedor, con más herramientas que los respaldan y el potencial de estandarización. Será interesante ver cómo evolucionan los monorepos sin los desafíos planteados por la gestión de paquetes. El orador expresa entusiasmo por el futuro de los monorepos y las posibilidades que ofrece. También menciona la presencia de nuevas herramientas y el potencial de desarrollo adicional en el espacio de los monorepos.

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.

11. Mi Trayectoria en la Programación

Short description:

Comencé a programar a los 13 años en 1983. Obtuve mi primera computadora y supe que la programación era lo que quería hacer. Me uní al Ejército y formé parte de una unidad de computadoras. Durante los últimos 30 años, he estado involucrado en la programación y me encanta.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.

Workshops on related topic

React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Featured WorkshopFree
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Node Congress 2023Node Congress 2023
160 min
Node Monorepos with Nx
WorkshopFree
Multiple apis and multiple teams all in the same repository can cause a lot of headaches, but Nx has you covered. Learn to share code, maintain configuration files and coordinate changes in a monorepo that can scale as large as your organisation does. Nx allows you to bring structure to a repository with hundreds of contributors and eliminates the CI slowdowns that typically occur as the codebase grows.
Table of contents:- Lab 1 - Generate an empty workspace- Lab 2 - Generate a node api- Lab 3 - Executors- Lab 4 - Migrations- Lab 5 - Generate an auth library- Lab 6 - Generate a database library- Lab 7 - Add a node cli- Lab 8 - Module boundaries- Lab 9 - Plugins and Generators - Intro- Lab 10 - Plugins and Generators - Modifying files- Lab 11 - Setting up CI- Lab 12 - Distributed caching
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.