La Era de los Monorepos

Rate this content
Bookmark

La historia de la web se puede dividir en saltos evolutivos en el desarrollo. La era de los scripts en línea, la era de jQuery, la era de las SPAs, la era de JAMStack...

Ahora estamos entrando en la siguiente etapa que ha sido cuidadosamente preparada en los últimos años. Permíteme invitarte al mundo de las soluciones modernas de monorepo y compartir contigo los beneficios que obtendrás al usarlas en proyectos de cualquier tamaño y configuración. Es hora de automatizar esas tareas de boilerplate y reducir los cuellos de botella para que puedas centrarte en lo que realmente importa.

¡Prepárate para el próximo salto! ¡Bienvenido a la era de los monorepos!

25 min
16 Jun, 2022

Video Summary and Transcription

La charla de hoy trata sobre el mundo de los monorepos, su historia, beneficios y características. Los monorepos abordan desafíos en el desarrollo web, como procesos de compilación lentos y conexiones inestables en dispositivos móviles. La colocación en monorepos permite compartir fácilmente funciones y componentes entre proyectos. La velocidad y eficiencia en los monorepos se logran a través de la colocación, los gráficos de dependencia y la orquestación de tareas. Herramientas de monorepo como Learnr ofrecen características como el almacenamiento en caché y la ejecución distribuida de tareas. Los monorepos proporcionan compartir código, herramientas consistentes y migración automatizada, lo que resulta en una experiencia de desarrollo 10 veces mejor.

Available in English

1. Introducción a los Monorepos

Short description:

Gracias a todos por unirse a mi charla. Hoy voy a hablar sobre el increíble mundo de los monorepos. Pero antes de sumergirnos en eso, tengo un importante aviso legal. En esta diapositiva, verán algunos ejemplos de un diseño web extremadamente malo. Verán algunos colores parpadeantes que podrían causar ataques de felicidad. Y finalmente, verán algunas características que cambiarán sus vidas.

Desafortunadamente, el MC decidió renunciar en el último momento, así que tengo que presentarme yo mismo, pero está bien. Hoy voy a hablar sobre el increíble mundo de los monorepos. Pero antes de sumergirnos en eso, tengo un importante aviso legal. En esta diapositiva, verán algunos ejemplos de un diseño web extremadamente malo. Verán algunos colores parpadeantes que podrían causar ataques de felicidad. Y finalmente, verán algunas características que cambiarán sus vidas. Así que, si tienen antecedentes médicos con alguno de estos síntomas, tal vez sea mejor cambiar de tema. De lo contrario, asumo que asumen la plena responsabilidad de estar aquí.

2. Introducción a la Historia del Desarrollo Web

Short description:

Y con esa nota formal, permítanme presentarme. Mi nombre es Miroslav Janas. Trabajo para Narval en la herramienta llamada nX. Antes de sumergirnos en lo que son los monorepos, hagamos un viaje al pasado para entender cómo llegamos aquí. Al principio, la web era estática. Las páginas eran aburridas, pero luego los lenguajes de programación como JavaScript trajeron dinamicidad. A medida que los sitios web se volvieron más complicados, surgieron las aplicaciones de una sola página. Sin embargo, el auge de los teléfonos inteligentes trajo nuevos desafíos con conexiones inestables.

Y con esa nota formal, permítanme presentarme. Mi nombre es Miroslav Janas. Trabajo para Narval en la herramienta llamada nX, de la que escucharán mucho hoy. También coorganizo dos encuentros en Viena, ViennaJS y AngularVienna.

Ahora, antes de sumergirnos en lo que son los monorepos, para entender cómo llegamos al punto en el que se necesitan los monorepos, debemos hacer un viaje al pasado, hasta los inicios de la web, para rastrear nuestros pasos y ver cómo llegamos aquí. Abróchense los cinturones, es hora de la historia.

Al principio, como todos saben, la web era estática. Era simplemente una colección de páginas HTML enlazadas con hipervínculos. Las primeras páginas web se veían algo así como esta página de Yahoo. Tenían mucho texto, muchos enlaces, imágenes muy pequeñas, era la época de la conexión dial-up, por lo que las cosas tenían que ser pequeñas y rápidas. Por lo general, tenían una elección de colores contrastantes, pero las páginas eran aburridas. Eran demasiado estáticas, así que la gente ideó un formato gráfico que daría un poco de vida. ¿Quién recuerda a este bebé bailarín? Algunas páginas llevaron esto a un nivel completamente nuevo, donde toda la página estaba girando en animations. Pero verán, aún no era lo que necesitábamos porque esto se ejecutaba en un bucle, no era una animación controlada, no era un movimiento controlado. Entonces, a Brendan Eich de Netscape, una empresa que producía el navegador popular en ese momento, se le asignó la tarea de crear un lenguaje en solo dos semanas que recogiera algunas ideas de Java y que finalmente llevara dinamicidad al navegador. Y dos semanas después, nació LiveScript, que luego se renombró a JavaScript, para deleite de generaciones de reclutadores y cazatalentos desde entonces.

Y así comenzó la era de la programación de scripts y con esto finalmente tuvimos páginas con galerías de imágenes elegantes, teníamos efectos de menú locos, botones que huían de nuestro cursor, pero las páginas, bueno, todavía podían verse muy feas, pero al menos tenían movimiento controlado finalmente. Y a medida que el número de scripts en una página crecía, comenzamos a encontrar ciertos patterns para reconocer ciertas cosas que se repetían. Al mismo tiempo, este fue un momento de famosas guerras de navegadores entre Microsoft y Netscape y había muchas inconsistencias entre los estándares en estos dos navegadores, por lo que los desarrolladores generalmente tenían que implementar cosas para ambos navegadores. Afortunadamente, ahora teníamos bibliotecas de ayuda, especialmente jQuery, que superaría estas diferencias y crearía una envoltura alrededor de la manipulación del DOM. Esto te permitiría crear rápidamente tus sitios web. Y a medida que los sitios web se volvieron más y más complicados, comenzamos a llamarlos aplicaciones web, no sitios web.

Pero encapsular el DOM y las animations no era la única plantilla. Todavía había mucho por encapsular, como el enrutamiento, la gestión de eventos, la gestión del estado, y esto fue lo que llevó a las aplicaciones de una sola página. El primer framework popular que implementó aplicaciones de una sola página fue AngularJS, y pronto le siguieron React y Vue. Todos ellos todavía se usan hoy en día en algunas variaciones y juntos cambian nuestra forma de pensar en el desarrollo web. Establecieron el desarrollo web tal como lo conocemos hoy. Desafortunadamente para ellos, este también fue el momento en que nuestros teléfonos se volvieron inteligentes y ahora de repente ya no navegamos por Internet en nuestras computadoras de escritorio, sino que comenzamos a navegar por Internet en nuestros teléfonos móviles mientras estábamos sentados en bancos de parques o en transporte público o sentados en un asiento de inodoro. En estos lugares, la conexión no era realmente estable. Podíamos esperar como máximo 3G con muchas interrupciones.

3. Monorepos y Colocación

Short description:

Las aplicaciones de una sola página eran demasiado pesadas para los teléfonos móviles, lo que llevó al surgimiento de Jamstack. Sin embargo, esto se hizo a expensas de la experiencia del desarrollador y los procesos de compilación lentos. Los monorepos abordaron estos problemas al permitir que las diferentes partes del sistema se notifiquen inmediatamente entre sí de los cambios. La colocación en un monorepo permite compartir fácilmente funciones y componentes entre proyectos.

Y de repente nos dimos cuenta de que las aplicaciones de una sola página eran demasiado pesadas para los teléfonos móviles y necesitábamos abordar esto. Y la gente estaba acostumbrada a tener sitios web rápidos, así que de repente, cuando tenías que esperar minutos para que algo se cargara, simplemente no funcionaba. Y esto llevó al surgimiento de Jamstack, donde necesitábamos algo que fuera rápido y ligero en contraste con las grandes aplicaciones de una sola página que tardaban minutos o incluso decenas de minutos y megabytes en cargarse.

Necesitábamos abordar el elefante que intenta ser exprimido por una pajita. Fue el nacimiento de los primeros meta frameworks como Next, Nuxt o Gatsby o los populares hoy en día Remix, Quik y Astro que aportan algo nuevo, donde finalmente teníamos páginas que se cargaban rápidamente, donde verías los resultados de inmediato. Desafortunadamente, todo esto se hizo a expensas de la experiencia del desarrollador. Para tener sitios web rápidos para los usuarios, teníamos que hacer un trabajo pesado en nuestras propias máquinas, por lo que nuestros procesos de compilación se volvieron extremadamente lentos. Y no solo esto frustraba a los desarrolladores, sino que cuando consideramos que la mayoría de las CI y CD ahora se realiza en la nube, si nuestros procesos de compilación eran lentos, eso también significaba que nuestros compilaciones mensuales en la nube eran cada vez más altas.

Era hora de abordar la segunda parte de la lentitud, por lo que ahora los sitios web eran lentos pero necesitábamos trabajar rápido, pero necesitábamos acelerar nuestra experiencia del desarrollador. Esto llevó a los monorepos. Para entender qué hacen exactamente los monorepos, consideremos primero nuestra aplicación web típica de hoy en día. Nuestra aplicación generalmente consta de una aplicación de front-end construida con el framework elegido, y luego tenemos algún back-end que no es un back-end monolítico, sino que tiene una arquitectura de microservicios detrás, y luego tienes algunos componentes de interfaz de usuario. Ahora, lo que sucede ocasionalmente es que uno de los desarrolladores que trabaja en el back-end cambia ligeramente un método en uno de los servicios, cambiando así un contrato, y simplemente olvida informar al mantenedor del front-end, y de repente tu sitio web está roto, todos te están señalando con el dedo y no tienes idea de qué sucedió porque no tocaste ese código.

Hay algunos intentos torpes de resolver esto exportando constantemente contratos desde el back-end, convirtiéndolos a TypeScript e importándolos en tus aplicaciones de front-end para tener siempre información actualizada, pero esto requiere intervención manual y cuando se trata del factor humano, dado suficiente tiempo, eventualmente fallará. Y además de eso, hay un problema de sincronización porque si algo cambia en el back-end, tienes que implementarlo al mismo tiempo en el front-end, y hay mucha coordinación y malabarismo involucrado. Además de eso, tu aplicación puede no ser la única. Puede haber dos aplicaciones adicionales, una dedicada a móviles y un portal de administración dedicado tal vez construido con una tecnología completamente diferente que también se comparte entre diferentes aplicaciones.

Ahora, lo que quieres hacer es que cada vez que uno de estos cambie, cada parte del sistema que se haya visto afectada por él sea notificada de inmediato. Ahora, en un enfoque de poli-repo típico, lo que sucede es que, por ejemplo, si cambias la utilidad, tendrías que publicar una nueva versión, luego actualizar las dependencias en la aplicación de la página de inicio y el portal de administración, y luego probar si esto funciona. Si no funciona, tienes que volver atrás, hacer una corrección en la utilidad y publicar una nueva versión. Por supuesto, esto se puede resolver con, por ejemplo, enlaces SIEM o algún repositorio local, pero requiere mucha coordinación, muchas cosas que debes mantener y además de eso, esto no escala bien.

Ahora, ¿no sería bueno si simplemente pudieran hablar entre sí? Entonces, cada vez que algo cambie, todo el ecosistema ya sabe qué sucedió. Y esto es lo que sucede con la colocación. La colocación significa que todos estos proyectos están en el mismo repositorio. Entonces, cada vez que uno de estos cambia, todos los proyectos pueden verlo de inmediato porque están juntos, por lo que no es necesario publicar una nueva versión, no es necesario ningún despliegue o cualquier otro ritual. Ahora, tener las cosas colocadas también nos ayuda a identificar ciertas funciones que se pueden, por ejemplo, reutilizar. Entonces, si tienes alguna función sofisticada de administración como esta en tu código, puedes decirle fácilmente a tus colegas: `Oye, tengo esta increíble función, tal vez quieras usarla en tu proyecto también`. Y ellos pueden verlo y decir: `Sí, increíble, también necesitamos esto para el teléfono móvil`. Y puedes extraer esto fácilmente en una biblioteca y compartirla con todos los demás en el repositorio. Y cuando la gente piensa en los monorepos, esto es lo que generalmente piensan, que se trata solo de la colocación. Pero no se trata solo de la colocación.

4. Logrando Velocidad y Eficiencia en Monorepos

Short description:

La colocación es el primer paso para lograr velocidad en los monorepos. Al tener todo colocado en un mismo lugar, podemos identificar fácilmente las conexiones y crear gráficos de dependencias. Esto nos permite optimizar nuestros procesos de compilación y despliegue, reduciendo el tiempo y esfuerzo requeridos. Además, podemos mantener gráficos de dependencias y arquitectura actualizados, eliminando la necesidad de diagramas obsoletos. Con este conocimiento, podemos orquestar tareas de manera más eficiente, ejecutándolas en paralelo y optimizando el orden de ejecución. Los avances recientes en herramientas de monorepo, como Lerna con el uso de NX, lo han vuelto aún más poderoso y competitivo. Visita el nuevo sitio web para obtener más información.

La colocación es solo una condición previa para todo lo demás. Es la velocidad lo que más destaca en los monorepos. Entonces, ¿cómo logramos esta velocidad? En primer lugar, cuando tenemos todo en un mismo lugar colocado, podemos identificar fácilmente cómo están conectadas las cosas. Y al saber cómo están conectadas las cosas, podemos crear este bonito gráfico de dependencias. Por ejemplo, si cambiáramos aquí nuestra biblioteca principal, podemos ver que los únicos dos proyectos que podrían verse afectados son store y admin.

Además, si el comando que estamos intentando ejecutar es deploy, sabemos que esta biblioteca principal es solo un bloque de construcción, no se despliega. Así que no hay nada que hacer allí. Pero nuestros store y admin sí se despliegan. Por lo tanto, al saber qué objetivo estamos ejecutando y cómo están conectadas las cosas, podemos reducir este gráfico completo a solo dos nodos. Ahora imagina si este gráfico completo tuviera cientos de proyectos. ¿Cuánto ahorrarías allí? En lugar de ejecutar build, por ejemplo, para todos estos proyectos, simplemente ejecutarías build para core, store y admin, y luego desplegarías solo store y admin.

Nuevamente, si sabemos cómo están conectadas las cosas, siempre podemos tener un gráfico de dependencias actualizado. Podemos tener un gráfico de arquitectura actualizado. Así que ya no tienes que mantener diagramas arquitectónicos obsoletos en tus unidades de red. Simplemente puedes ejecutar el comando y obtener un diagrama actualizado de inmediato. Y no solo eso, puedes filtrarlo fácilmente por nodos, puedes hacer clic en los vértices y ver qué archivos crean esta conexión entre dos proyectos. Puedes ver si tienes algunas dependencias circulares. Puedes detectar todos estos problemas. Si sabemos cómo están conectadas las cosas, podemos crear una buena orquestación de tareas, porque podemos saber en qué orden deben procesarse las cosas. Entonces, si necesitamos, por ejemplo, ejecutar test, build y lint, una forma ingenua sería simplemente ejecutarlos secuencialmente, primero build, luego lint y luego test. Supongamos que test incluye pruebas de extremo a extremo, por lo que debemos hacerlo después de la compilación. Una mejor forma sería, por supuesto, ejecutar build y lint en paralelo porque no dependen entre sí, y luego ejecutar test después. Una forma aún mejor sería comenzar a ejecutar las pruebas tan pronto como las partes que deben ser probadas estén construidas. Y si alguna vez usaste Learnr hasta hace un mes, este era el límite de sus capacidades. Y estaba bien para la mayoría de las cosas, pero también dejaba mucho que desear. Y en este estado de limbo, surgieron muchas nuevas herramientas de Monorepo y ofrecieron más funcionalidades sobre Lerna. Esto cambió recientemente cuando Narwal se hizo cargo de Lerna, porque ahora con una sola bandera use NX, puedes tener la mayoría de las funcionalidades que NX, una de las herramientas populares de Monorepo, proporciona. Entonces, Lerna ahora también es competitivo con todas las demás herramientas y se volvió mucho más rápido que antes. Y también hay un nuevo sitio web, así que si no lo has revisado, puedes ir y revisar el sitio web. No ahora, después de la charla.

5. Herramientas y Automatización de Monorepo

Short description:

Como mencioné, ahora está impulsado por NX. Empresas como Google y Facebook han tenido sus soluciones de Monorepo durante mucho tiempo, pero configurarlas requería muchas configuraciones manuales. Afortunadamente, empresas como Microsoft, Narwa y Verso ofrecen soluciones automatizadas que simplifican el proceso.

Como mencioné, ahora está impulsado por NX. Esto es opcional, por lo que puedes activarlo o desactivarlo si no te gusta, depende de ti. Entonces, ¿cuáles son estas otras herramientas de Monorepo? Empresas como Google y Facebook han tenido sus soluciones de Monorepo durante mucho tiempo. Los repositorios consisten en miles de proyectos que se ejecutan constantemente y para este tipo de ecosistema, necesitas herramientas de construcción realmente sofisticadas para ejecutar esto en tiempo real, ¿verdad? Y tomó mucho tiempo que esto sucediera. Pero hasta hace poco, no estaba abierto al público. Pero una vez que se abrió al público, aunque nos dimos cuenta de lo impresionantes que son estas herramientas, había un pequeño inconveniente. Podrías necesitar un doctorado para poder configurarlo, porque casi nada estaba automatizado. Requería muchas configuraciones, y no solo una vez. Una y otra vez, cada vez que creas un nuevo proyecto. Entonces, para mantener esto en tu repositorio, podrías necesitar a una persona dedicada que haga solo esto. Esto no era, por supuesto, factible para ninguna empresa más pequeña. Pero afortunadamente, empresas como Microsoft, con Rush y Lagge, o Narwa con NX, o Verso ahora con TurboRepo, ofrecieron soluciones que brindan más o menos el mismo conjunto de funciones, pero automatizadas, sin todas las plantillas que debes hacer manualmente.

6. Características de Learnr: Caché y Caché Remoto

Short description:

La característica más importante que falta en Learnr es la caché. La caché te permite evitar ejecutar código que ya has ejecutado. Almacena artefactos de construcción y bloqueos en una caché, por lo que cuando ejecutas una construcción nuevamente, puede reproducir los resultados desde la caché. Con una caché remota, puedes almacenar tu caché localmente o en la nube, ahorrando tiempo en CI y reduciendo los costos en la nube.

Entonces, ¿cuáles son estas características que nos faltan en Learnr? La más importante es la caché. La caché es una premisa de que no deberías tener que ejecutar código que ya has ejecutado. Entonces, si estás ejecutando, por ejemplo, una construcción en tu estado del repositorio, si necesitas ejecutarlo nuevamente, deberías tener solo los resultados reproducidos. ¿Por qué luchar de nuevo? Y esto es lo que hace la caché.

Por ejemplo, si ejecuto una construcción en mi sistema, se almacenará en una caché. Y no solo mis artefactos, sino también mis bloqueos. Entonces, la próxima vez que lo ejecute, no solo copiará esos artefactos como si estuviera ejecutándolo ahora, sino que también reproducirá todos los bloqueos, por lo que ni siquiera notarías que se estaba ejecutando desde una caché aparte de estar allí de inmediato.

Pero, ¿qué sucede si tienes un colega, por ejemplo, en Australia, y están ejecutando el mismo comando en el mismo estado del repositorio? Tendrían que hacerlo nuevamente, porque no pueden ver tu caché local. Pero afortunadamente, con una caché remota, no solo puedes almacenar tu caché localmente, sino que también puedes almacenarla en la cloud. Entonces, la próxima vez que tu colega intente cargar o ejecutar la construcción, primero verificará si está disponible en mi caché local. Si es así, lo copiaremos desde la caché local, si no, verificaremos la cloud. ¿Está allí? Si es así, lo copiaremos desde la cloud, de lo contrario, lo ejecutaremos desde cero, lo guardaremos en la caché local y lo guardaremos en la cloud. Y esto no solo ahorra tiempo al desarrollador, sino que también ahorra una cantidad tremenda de tiempo en CI, especialmente porque mientras trabajas en tu PR en tu función, ya estás construyendo estas cosas en tu máquina, y tu cloud ya lo sabe. Entonces, cuando ejecutas el CI, el CI solo recoge cosas de la caché. Y esto no solo ahorra tiempo mientras esperas el PR, sino que también ahorra una gran cantidad de dinero en tus facturas mensuales de la cloud.

7. Ejecución de Tareas Distribuidas

Short description:

La siguiente característica muy interesante es la ejecución de tareas distribuidas. Permite ejecutar tareas en paralelo o en múltiples agentes, lo cual es crucial para manejar cambios importantes o refactorizaciones en un monorepo. La ejecución de tareas distribuidas es el problema más difícil de los monorepos y actualmente solo Bazel y NX lo están implementando.

La siguiente característica muy interesante es la ejecución de tareas distribuidas. No importa cuán buena sea la implementación de tu caché, o cuán eficiente sea tu grafo afectado, hay ocasiones en las que todo esto no importa. Por ejemplo, si estás actualizando la versión de tu framework, de repente todo se ve afectado y tu caché deja de existir, porque tienes una versión completamente nueva del framework. Así que toda la caché que tienes deja de funcionar. Puede estar rota. Así que tienes que ejecutar todo desde cero. Y aunque esto pueda no parecer importante, hemos visto soluciones con cientos de proyectos donde simplemente ejecutar la construcción lleva una hora y media. Sus construcciones nocturnas duran un día y medio. Así que ni siquiera es nocturno, ya es por la noche. E imagina si tuvieran que ejecutar esto cada vez que algo importante cambie en su framework. O si tienen alguna refactorización importante, sería un desastre. Afortunadamente, la ejecución de tareas distribuidas nos da la capacidad de ejecutar cosas en paralelo o en múltiples agentes. Es decir, por ejemplo, si tenemos cien tareas que necesitamos completar, podemos dividirlas en, digamos, cinco agentes y cada uno toma 20 tareas. Pero no es tan simple porque las tareas no tienen el mismo tamaño. Pueden estar entrelazadas, puede haber dependencias. Y además de eso, si algo falla, no quiero revisar todos los agentes para ver exactamente dónde falló. Quiero ver un informe unificado. Y es por eso que la ejecución de tareas distribuidas es el problema más difícil de los monorepos. Y hasta ahora, solo dos soluciones de monorepos, Bazel y NX, lo están implementando.

8. Características y Beneficios de los Monorepos

Short description:

Las restricciones de código, los generadores potentes, la migración automatizada y las herramientas consistentes son características clave de los monorepos. Proporcionan claridad, velocidad y eficiencia en el desarrollo de proyectos. Los monorepos permiten a los desarrolladores restringir el acceso a los proyectos, configurar generadores de línea de comandos, automatizar migraciones y mantener herramientas consistentes. También ofrecen análisis del espacio de trabajo, visualización de gráficos, almacenamiento en caché local y remoto, orquestación de tareas y ejecución de tareas distribuidas.

La siguiente característica muy interesante son las restricciones de código. Esta es tu única arma contra arquitecturas inmanejables. Estás trabajando en algunas características experimentales y, hasta que termines completamente y aún estés experimentando, de repente alguien comienza a usar tu característica en su proyecto. Y ahora no solo tienes una dependencia, que cada vez que cambias algo, podría romper el cambio para ellos, sino que si decides que todo tu experimento fue un fracaso y prefieres eliminar esta característica, ya no puedes hacerlo porque alguien depende de esto.

Las restricciones de carga son la capacidad de restringir el acceso a tu proyecto, de especificar el tipo de proyecto que puede acceder a esto. Podría ser tan simple como si tienes, por ejemplo, Angular y React en tu repositorio, puedes decir que las bibliotecas de Angular no deben cargar las bibliotecas de React. Pero, ¿qué pasa si solo tienes un proyecto? ¿Deberías seguir usando los monorepos? La respuesta es simple. Absolutamente, sí.

También proporcionan generadores potentes. Normalmente, cuando comienzas un proyecto, lo haces con una CLI que genera y estructura proyectos para ti. La mayoría de las veces está bien. Pero a menudo no lo está. Por eso hay tantos proyectos de plantilla que te llevan un paso adicional. Ahora, imagina si pudieras configurar tu CLI para generar cosas como te gustan, con pruebas unitarias, con pruebas de extremo a extremo, con tu configuración de gestión de estado de la forma que te gusta, con todas las utilidades y aplicaciones tal como te gusta. Con NX, por ejemplo, tienes estos generadores potentes donde realmente puedes configurar todo y no solo en el momento de la inicialización, sino también cada vez que creas un nuevo componente o una nueva función o un nuevo proyecto puedes especificar cómo debería verse.

También te brinda la capacidad de migrar cosas de manera sencilla. Así que imagina que hay una nueva versión de tu framework BelowIt y, por supuesto, hay algunos cambios importantes. Normalmente, tendrías que ir a tu código y solucionar todos esos problemas y arreglarlos manualmente. Con generadores, con migración automatizada, puedes simplemente ejecutar la migración y solucionará todo esto por ti. Y finalmente, tenemos herramientas consistentes. No sé tú, pero para mí siempre fue molesto cuando cambiaba entre diferentes frameworks y luego tenía que recordar si era NPM start o NPM serve o si era NPM develop. Y no se trata solo de servir aplicaciones. Todos estos comandos tienen diferentes parámetros y formas diferentes de ejecutarse. Por lo tanto, las herramientas consistentes crean un envoltorio alrededor de estos comandos para que siempre puedas ejecutar los comandos de la misma manera, independientemente del framework que esté debajo o si es next o next o si es Cypress o ESLint y no solo son comandos, son parámetros que siempre son los mismos. Por lo tanto, solo necesitas aprender un conjunto de comandos. Incluso esto no tienes que hacerlo porque aquí lo que olvidé mencionar es que también proporcionamos extensiones para VS Code que te brindan esta agradable representación gráfica de todos los generadores para que puedas encontrar fácilmente el generador que te gusta y te brindará información sobre todos los parámetros que necesitas pasar. No tienes que recordar nada.

Entonces, recapitulemos. Los monorepos brindan claridad al proporcionarnos análisis del espacio de trabajo y visualización de gráficos. Nos brindan velocidad al aprovechar el almacenamiento en caché local y remoto, la orquestación de tareas, la detección de nodos afectados y la ejecución de tareas distribuidas.

9. Beneficios de los Monorepos

Short description:

Los Monorepos facilitan el desarrollo con el intercambio de código, la colocación, los generadores, las herramientas consistentes y las restricciones de código. Visita monorepos.tools para comparaciones. Usa NX para una experiencia de desarrollador 10x.

Y finalmente, hacen nuestra vida de desarrollo más fácil porque nos brindan intercambio de código, colocación de código, generadores potentes, herramientas consistentes y restricciones de código. Si quieres saber cómo se comparan entre sí diferentes soluciones de monorepos, puedes dirigirte a monorepos.tools, que te ofrece una comparación detallada con todas las características enumeradas. Y este sitio web de código abierto ha sido mantenido por los creadores de populares soluciones de monorepos. O, si no quieres perder tanto tiempo, puedes simplemente confiar en mi palabra y usar NX. Y si te preguntas si esto es lo que finalmente te convertirá en un desarrollador 10x, ¿por qué conformarte con 10x cuando puedes ser un desarrollador NX? Gracias y disfruta de la conferencia. Muy bien. Vamos un poco retrasados, así que solo vamos a responder una pequeña pregunta de la sesión de preguntas y respuestas. Pregunta de un anónimo. ¿Qué pasa con tener múltiples versiones del mismo framework, como una aplicación con React 17 y React 18? Todas las soluciones proporcionan la posibilidad de tener módulos de nodo agrupados. Esto significa que cada proyecto puede tener su propio package JSON y su propio conjunto de dependencias. Por lo tanto, puedes tener en un proyecto React 16, en otro React 17 y en el tercero React 18. Por supuesto, te recomendamos que intentes nivelar todas esas versiones para que tengas un lugar central donde se establezcan todas las dependencias. Pero si eso no funciona por alguna razón, simplemente puedes agruparlas con tus proyectos. Todo está bien. Todo está bien. Bueno, muchas gracias, Miro. Gracias. Un gran aplauso para Miro. Y ahora pasaremos a nuestro próximo ponente.

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

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.
React Summit 2022React Summit 2022
21 min
Scale Your React App without Micro-frontends
As your team grows and becomes multiple teams, the size of your codebase follows. You get to 100k lines of code and your build time dangerously approaches the 10min mark 😱 But that’s not all, your static CI checks (linting, type coverage, dead code) and tests are also taking longer and longer...How do you keep your teams moving fast and shipping features to users regularly if your PRs take forever to be tested and deployed?After exploring a few options we decided to go down the Nx route. Let’s look at how to migrate a large codebase to Nx and take advantage of its incremental builds!
Remix Conf Europe 2022Remix Conf Europe 2022
22 min
Remixing Your Stack in a Monorepo Workspace
Remix entered the stage with a unique and refreshing take on how to develop on the web. But how do you integrate it into your existing ecosystem of applications? Do you want to test-drive Remix on a small project, or do you want to go full-in, but it is tricky to do a big-bang migration from your existing React app? In this talk, we're going to explore how a monorepo-based code organization can help integrate Remix with your existing React and TypeScript infrastructure, facilitating high code reuse and a migration path to Remix.
React Summit 2022React Summit 2022
22 min
Fast React Monorepos with High Quality DX
Monorepos have been around for some time but only recently gained popularity in the JavaScript community. The promise of easily sharing code, better enforcing organizational standards, greater developer mobility due to common tooling, and more is very appealing. Still, if approached naively, a monorepo will quickly turn into a huge mess: skyrocketing slow CI times, spaghetti dependencies among projects, hard to navigate, and ultimately leading to frustration. In this talk, we will look at the available tooling, how to kickstart a new React monorepo in particular, and we will learn the key ingredients required to build a successful, long-running monorepo that scales.

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