Desarrollo escalable de React para proyectos grandes

Hola a todos. Mi nombre es Jason. Estoy aquí para hablarles sobre el desarrollo escalable de React facilitado por NX. Primero, voy a hacer una introducción sobre mí mismo, y también voy a presentar el concepto de un monorepo, y luego voy a profundizar más en lo que es NX y cómo puede ayudarte a escalar tu desarrollo de React. Luego haremos una demostración en vivo al final, si tenemos tiempo. Así que empecemos.

Un poco sobre mí, pueden encontrarme en Twitter como Fersenpandas. Soy arquitecto en Narwal. Y también soy parte del equipo principal de NX. Trabajo en NX como parte de mi trabajo a tiempo completo. En Narwal, asesoramos a empresas Fortune 500. Somos expertos en desarrollo de código en monitoreo, y también creamos herramientas de desarrollo para acelerar el desarrollo de código en monitoreo. Así que mi trabajo consiste en acelerar el trabajo de las empresas de manera más rápida y eficiente. Y ahí es donde entra NX.

Pero antes de hablar sobre NX, permítanme contarles un poco sobre los monorepos. Primero quiero decir lo que no es un monorepo, porque hay muchas ideas equivocadas. Luego les diré qué es y por qué alguien podría querer usar un monorepo. Una idea equivocada sobre un monorepo es que no es una aplicación monolítica. Esto significa que no tienes que construirlo todo de una vez. No tienes que construir una gran aplicación a partir de un monorepo. Y tampoco tienes que implementar todo el monorepo de una vez. Permítanme explicar más sobre qué es un monorepo, para que vean dónde está la idea equivocada. Un monorepo es simplemente un repositorio único que tiene múltiples proyectos, lo que significa que hay un fragmento de código que vive en un directorio, y otro fragmento de código que vive en otro directorio, pero todo está bajo un control de versiones. Lo veo como un almacén de código. En un almacén, tienes paquetes que están empaquetados por separado por diferentes personas. Se almacenan juntos en un almacén, pero luego se envían por separado a diferentes personas. Y lo mismo ocurre con los proyectos dentro de un monorepo. Se desarrollan de forma independiente en un repositorio, pero se implementan de forma independiente. ¿Quién utiliza monorepos? Facebook, Microsoft, Google, todos utilizan un monorepo, al igual que otras grandes empresas de tecnología. Y no creo que sea una coincidencia que muchas de estas exitosas empresas de tecnología hayan adoptado un enfoque de monorepo para el desarrollo.

Entonces, veamos por qué eligen hacerlo así. Veamos cómo desarrollamos aplicaciones sin monorepos. Así que, tengo mi aplicación, pero también divido la funcionalidad en diferentes partes del código, ¿verdad? Para que mi código esté organizado. Agrupo todo en un repositorio Git. Configuro NPM, y configuro Jenkins o Travis, y todo funciona en conjunto. Puedo trabajar en diferentes partes del código, así como en la aplicación misma al mismo tiempo. Y luego, puedo probar todo de una vez. Y este es un flujo de trabajo con el que muchas personas están familiarizadas.

Sin embargo, pronto necesitaremos compartir el código entre diferentes aplicaciones dentro de nuestra organización. No solo tenemos la aplicación de coche, sino que también podemos tener una API y una aplicación de tienda también. Y es posible que deseen acceder a partes del código que hemos escrito previamente para la aplicación de coche. Por lo tanto, esto es realmente difícil de hacer porque todo está en un solo repositorio y no puedes traer las partes del coche sin traer el coche completo.

Entonces, voy a hablar sobre cómo compartir código en múltiples repositorios, algo con lo que muchos de ustedes probablemente están acostumbrados, y esta será la forma más complicada de las dos. Así que, cuando te das cuenta de que quieres compartir código, decides que eso significa que tienes que dividir todo mi código en diferentes repositorios. Así que, sigues adelante y creas todos estos repositorios de Git y la gente trabaja en ellos. Esto inmediatamente introduce la necesidad de herramientas duplicadas. No solo tienes múltiples repositorios, también tienes múltiples flujos de CI, también tienes múltiples versiones de las dependencias de NPM y todo eso. Y para cada repositorio que configures, necesitas esto.

Junto con las herramientas duplicadas, también tienes que separar tu flujo de trabajo. Cuando trabajas en esta biblioteca aquí, solo puedes ejecutar esas pruebas porque las otras pruebas están en diferentes repositorios, así que estás limitado a ejecutar solo estas pruebas. Por lo tanto, no sabes si la aplicación de coche está rota o no, así que tienes que hacer algo de trabajo allí también. Luego puedes ejecutar esas pruebas, pero también te darás cuenta de que la API también depende de su biblioteca, así que tienes que hacer lo mismo allí. Y esto es como tres fases diferentes de tu flujo de trabajo, es muy discontinuo, y pierdes mucho contexto al cambiar de un lugar a otro. No como antes, donde podíamos trabajar en la aplicación de coche y en nuestra biblioteca al mismo tiempo. Pero, porque la gente quiere compartir código, esto es con lo que tenemos que lidiar.

Además, esas líneas claras que he dibujado entre estos proyectos son menos analizables cuando se utilizan múltiples repositorios. Los múltiples repositorios suelen estar vinculados a través de métodos como npm, a través de package.json y cosas así, y es realmente difícil poder analizarlos, por lo que esas líneas se vuelven menos visibles cuando miramos nuestra organización en su conjunto. Todo lo que sabemos es que tenemos, ya sabes, seis repositorios diferentes, pero esos están relacionados de maneras que no podemos analizar fácilmente a través del análisis de código. Luego, también podemos desincronizarnos. Muchas veces, cuando dividimos las cosas en diferentes repositorios, publicamos diferentes versiones, así que al principio, todo puede ser una versión 1. Funciona en conjunto. Es genial. Pero luego, en la biblioteca inferior aquí, podemos lanzar una segunda versión, ¿verdad?, que tiene algunos cambios, y otras bibliotecas tienen que incorporar esos cambios. Entonces, el de la derecha lo incorporará y se actualizará a la versión 2 de esta biblioteca inferior, pero la biblioteca de la izquierda elegirá hacerlo más tarde.

Así que, por ahora, se quedará en la versión 1. Y eso puede parecer una decisión aceptable en esta vista del mundo, pero cuando volvemos a nuestra organización, la aplicación de coche que utiliza ambas bibliotecas está muy confundida ahora sobre cuál es la versión correcta. Y lo más probable es que realmente traiga ambas versiones y nos encontramos en los días de jQuery donde hay tres versiones de jQuery en la página. Y esto también se aplica a las dependencias externas, como React.

Cuando las cosas están en diferentes repositorios, pueden depender de diferentes versiones de React, y en nuestra organización, podríamos tener la versión 16, la versión 15 y la versión 0.14, todas al mismo tiempo. Y cada aplicación podría usar una versión diferente, lo que podría generar confusión sobre qué versión debería utilizar y cosas así. Así que hablemos de cómo podemos hacer esto de manera más fácil y menos complicada.

Utilizando un monorepo, almacenaríamos todo este código en un solo repositorio. Y sé lo que todos están pensando, que esto no es escalable, pero más adelante les mostraré que sí lo es. Una cosa que vemos es que nuestras tooling nuevamente están unificadas. Tenemos un repositorio, un flujo de CI y dependencias de npm. Además, esas dependencias que hemos dibujado ahora son muy analizables. Parecen importaciones de este archivo, de este archivo, y podemos ver qué proyectos dependen de otros proyectos. De esa manera, puedo trabajar en ambos al mismo tiempo. Puedo trabajar en mi biblioteca, puedo trabajar en mi aplicación y cuando lo subo para ver si mis cambios se ven bien, también puedo ejecutar el conjunto específico de pruebas que son suficientes para verificar que mi cambio es preciso y bueno. Por lo tanto, las otras bibliotecas a la izquierda de la pantalla no tienen que ejecutarse porque mis cambios no las afectan en absoluto. También hay una única versión de cada proyecto y todas sus dependencias. Así que simplemente avanzamos. Cada vez que cambias a una nueva rama, tienes la misma versión que funciona con todo. Esto también significa que puedes hacer commit en múltiples proyectos con un solo commit y no tienes que preocuparte por mantenerlo sincronizado con las versiones. Y lo mismo ocurre con React. Así que una vez que actualizamos a la versión 16 de React, todo nuestro repositorio y todas nuestras aplicaciones están en la versión 16.

Así que he pasado por mucha información. Retrocedamos un poco y repasemos. Cuando utilizas múltiples repositorios, no tienes dependencias claras. Tienes múltiples versiones de todo y tienes muchas herramientas duplicadas. Cuando haces lo mismo a través de un monorepo, tienes un conjunto de herramientas. Tienes una única versión de dependencias. Y también puedes probar solo lo necesario en cada momento. Suena bastante bien. Entonces, al final del día, ¿por qué usar un monorepo? ¿No es solo la forma en que almacenas tu código? Y no creo que sea así. Creo que en realidad se trata de las personas. No solo se trata del código. Y nuestras personas están organizadas bajo una sola empresa y una sola organización.

Y todos somos un equipo. Aunque podemos tener diferentes responsabilidades dentro de nuestra organización, trabajamos como un equipo y tenemos un objetivo común. Así que veamos cómo podemos usar nx para implementar un flujo de trabajo de monorepo. nx es una herramienta de código abierto que te permite escalar tu desarrollo en múltiples equipos. Esto significa múltiples aplicaciones backend, frontend. Te permite hacerlo todo.

Lo primero que es una característica importante es que te permite desarrollar como Facebook. Entraremos en más detalles sobre lo que esto significa. Lo segundo es que tiene un sistema de construcción inteligente. Así como antes pudimos ver cómo se analizaban y probaban nuestros diferentes proyectos y nx es capaz de hacer eso. También admite el uso de herramientas modernas, como storybook y entraré en más detalles sobre cada una de ellas.

Entonces, para desarrollar como Facebook, como viste con el enfoque moderado, puedes compartir código muy fácilmente entre diferentes equipos. Esto también te brinda una experiencia de desarrollo integral. Tienes todos estos proyectos diferentes bajo un mismo techo y puedes ver cómo diferentes piezas funcionan entre sí y qué está sucediendo en cada parte del repositorio. Puede que no sea importante en todo momento, pero cuando estás trabajando en una tarea específica que involucra otra biblioteca, es maravilloso ver qué está sucediendo allí. Entonces, lo siguiente es cómo puedes mantener la consistencia. A través de la generación de código, podemos crear un espacio de trabajo sin configuración manual. Ejecutamos mpx create-nx-workspace con un conjunto predefinido de React y obtenemos este espacio de trabajo generado con nuestra nueva aplicación para el carrito.

Puedes agregar funcionalidad compartida muy fácilmente. Antes, tenías que crear un repositorio diferente, tenías que configurar un flujo de CI, publicar en NPM. Pero ahora puedes ejecutar nx generate-lib-shared-button, y ahora tienes un botón compartido que puedes utilizar en múltiples aplicaciones diferentes sin publicar en NPM y sin configurar un CI.

También puedes generar un estado Redux. Todos sabemos que hay mucho código repetitivo y aunque hay cambios en la herramienta Redux, aún hay mucho código que debes escribir para comenzar. Bueno, ahora puedes generarlo usando nx generate-redux-cart-directing-into-the-project-of-cart-state. Esto se genera automáticamente para ti, y puedes ver que podemos crear una sección con un carrito, e incluso tiene algunas acciones predefinidas que puedes cambiar después de generar el código.

También puedes agregar cosas como Next. Usando Yarn at rwnellnext y nx generate at rwnellnext app shop, puedes generar una nueva aplicación de tienda en el mismo repositorio que la aplicación de carrito sin mucha configuración en absoluto. Y Next está completamente configurado y listo para usar.

¿Qué pasa si no te gusta lo que NX genera? Hay tantas herramientas en el ecosistema que todos amamos y queremos usar, pero es comprensible que es posible que no te guste lo que NX decide generar para ti. Y también hemos tenido esa inspiración, puedes escribir esquemas de espacios de trabajo, que son una generación de código personalizada que se adapta a tu organización, utilizando las mejores prácticas de espacio de trabajo de NX. Y esto realmente permite que tu organización se mantenga consistente al generar el código que implementa las mejores prácticas que deseas tener. Esto es realmente útil cuando deseas integrarte con diferentes proyectos, deseas tener una forma consistente de organizar tu estado, y cosas así. Esta es una de mis características favoritas de NX.

Además, NX te ayuda a aplicar normas y mejores prácticas en toda tu organización. Entonces, antes hablábamos de generar código en el formato correcto, pero ¿qué pasa con el código que escribimos? Algo confuso acerca de un Monorepo a veces es que la gente piensa que cualquier biblioteca puede depender de cualquier otra biblioteca, y obtienes una bola de barro que no puedes desenredar y entender. Con NX, puedes etiquetar diferentes proyectos, por lo que el de la izquierda está etiquetado como state y el de la derecha está etiquetado como UI, y todos sabemos que el estado no debe depender de la interfaz de usuario (UI). Debería ser al revés. Entonces, si creamos una dependencia desde el estado hacia la UI, obtenemos un error de linting en nuestro editor. Permíteme hacer zoom para que puedas verlo completo. Un proyecto etiquetado como estado solo puede depender de estado, ¿verdad? No puede depender de estado o de un tipo de UI. NX también es lo suficientemente inteligente como para inferir tus dependencias. Como vimos antes, los proyectos dependen entre sí, y es importante saber cómo están estructuradas esas dependencias. Tomando el código como este, donde importo product UI y también product state desde mi aplicación, NX es capaz de inferir que esta aplicación, la aplicación actual, depende de estas dos bibliotecas sin que tengas que decirlo explícitamente. Luego, una vez que conocemos estas dependencias, también podemos visualizarlas para ti. Ejecutando NX Step Graph, puedes tener una vista interactiva de todas las dependencias dentro de tu proyecto. Entonces, a la derecha, ves que la página de inicio de productos depende de la UI de productos. Estas dependencias también son cruciales para el Intelligent Build System.

Cuando la gente piensa en monorepos, muchas veces piensan en ejecutar todo, ¿verdad? Y esto es lo que hace Lerna. Y a veces esto se extiende a 60 minutos, o incluso más. Y esto no es muy escalable si queremos hacer un PR y comprobar que funciona en cinco minutos.

Así que veamos algunas formas en las que podemos mejorar esto. NX te permite construir solo los proyectos afectados. Como vimos antes, para un pequeño cambio en este gran monorepo, no necesitamos probar todo. Por lo tanto, podemos extraer las partes del proyecto que son relevantes para nosotros en ese momento y probar solo esas partes, reduciendo nuestros tiempos a la mitad, a unos 25 minutos en este escenario hipotético.

Además, debido a que tenemos diferentes proyectos que se ejecutan de forma independiente, también podemos construirlos en paralelo en la misma máquina. Por lo tanto, podemos ejecutarlos en dos hilos diferentes, y puedes ver que nuestros tiempos, una vez más, se han reducido a la mitad. Luego, también puedes distribuir las compilaciones en múltiples agentes. No solo puedes paralelizarlos en la misma máquina, sino que también puedes distribuirlos. Por lo tanto, si tengo cinco trabajadores diferentes, ahora puedo probar estos cinco proyectos diferentes en nodos diferentes en mi CI. Y como puedes ver aquí, la barra roja allí todavía es bastante larga. Para acortarla, también podemos almacenar en caché las compilaciones anteriores. Si ya hemos realizado esta compilación antes, aunque mi cambio realmente la afecte, puede darse cuenta de que ya he realizado esta compilación antes. No lo hagamos de nuevo. Y puede obtener eso de una caché, reduciendo los tiempos a dos minutos.

Ahora, la mejor manera de hacer esto es a través de una caché remota, que puedes agregar agregando NX Cloud, que es nuestro complemento pago para NX. Pero NX es open-source, nuevamente, por lo que no necesariamente lo necesitas. Seis minutos es un tiempo más que favorable en comparación con los 60 minutos. Pero NX Cloud te permite no construir lo mismo dos veces.

Entonces, lo último es poder utilizar herramientas modernas. NX viene configurado de forma predeterminada con TypeScript, Jest, Cypress y Storybook. Estoy seguro de que todos están familiarizados con Jest, e incluso pueden tener sus propias opiniones sobre TypeScript, pero también puedes usar JavaScript dentro de tu repositorio con NX. Dos cosas con las que es posible que no estés familiarizado son Cypress, que es una experiencia de pruebas de extremo a extremo, por lo que no solo te permite escribir tus pruebas, sino que también te brinda una interfaz donde puedes viajar en el tiempo a través de esas pruebas y asegurarte de que no estés teniendo problemas al ejecutar tus pruebas de extremo a extremo. Storybook te permite desarrollar tus componentes de forma aislada, de la manera en que nos gusta pensar en ello durante nuestros desarrollos de React, y esto es realmente importante para poder ver cómo se ven estos componentes de la interfaz de usuario cuando están aislados de la aplicación en la que se desarrollan. También puedes instalar todos estos complementos por separado. Si no quieres Storybook, no tienes que instalar Storybook. Puedes instalar solo React y Next si quieres usarlo. También puedes instalar Node.js, Express y HTML si lo deseas, e incluso puedes instalar complementos de Angular y Nest.js.

Todo esto es a la carta, así que eliges lo que quieres y no tienes nada superfluo que no estés usando. También tenemos complementos de la comunidad. Tenemos la capacidad de que las personas de la comunidad creen complementos para sus herramientas favoritas, como migrar de Karma a Jest o implementar sin servidor. En nuestro muro, no podemos admitir todas las tecnologías existentes en cada proyecto de la comunidad, pero la comunidad ha hecho un gran trabajo creando complementos para que otras personas los usen. Y tú también puedes crear tu propio complemento. Si ejecutas mpx create-nx-plugin, creará un espacio de trabajo diferente para ti que sea adecuado para el desarrollo de complementos.

Así que con eso fuera del camino, vamos a hacer una demostración en vivo. Voy a entrar en un espacio de trabajo regular aquí. Ya está configurado, así que no te mostraré todos los pasos de generación de código, aunque vimos que era bastante fácil. La mayoría de este código aquí se configuró en una sola página. La mayoría de este código aquí se configuró mediante la generación de código, pero quiero echar un vistazo a nuestra aplicación de coche. En nuestra aplicación de coche, en nuestro componente principal, vemos que este archivo aquí importa desde un proyecto diferente llamado encabezado compartido. Así que como desarrolladores, sabemos que, obviamente, la aplicación de coche depende de la funcionalidad en el encabezado compartido. Entonces, cuando tenemos nuestro encabezado de ejemplo de Nx aquí, la funcionalidad no se encuentra dentro de este directorio aquí. En realidad, se encuentra en un directorio separado. Así que sigamos esa importación. Y tenemos nuestros elementos de encabezado. Siendo estos nuestros elementos de encabezado, podemos ver que así es como funciona sin tener que ir a un repositorio diferente. Si quisiera cambiar la forma en que funciona, puedo agregar un bloque de consola aquí. Hola, React Summit. Guardar esto. Ver que mis cambios están en Git. Y esto es genial. Puedo hacer un PR. Puedo verificar mi aplicación de coche aquí ejecutando current start cart. Y ahora puedo ver mi aplicación en ejecución con nuestros últimos cambios. Así que si abro esto. Dame un segundo. Vale, así que podemos ver que mi registro de consola aparece aquí. Tenemos el encabezado y nuestra aplicación de coche sigue viéndose bien.

Volviendo al código, ahora que hemos realizado estos cambios, no sabemos con certeza hasta que ejecutemos nuestras pruebas si la aplicación de coche se ve bien en CI. Podría probar mi encabezado compartido y luego, después de eso, puedo probar mi carrito. Así que puedo dejar que se ejecuten. Voy a confiar en que ambos funcionan, pero es un poco tedioso tener estas dependencias en mente todo el tiempo.

NX puede mostrarte esto. Si ejecuto 'effective test', revisará mis cambios en Git y se dará cuenta de que necesito verificar mi carrito y también necesito probar mi encabezado. Así que automáticamente lo sabe y no necesitas decírselo. Esto es genial para usarlo en CI, donde tienes un número arbitrario de cambios en múltiples proyectos y solo quieres probar lo que es necesario.

Y como te mencioné antes, puedes ver el gráfico de profundidad. Al ejecutar 'NX depth graph', se abrirá el gráfico de profundidad interactivo en un navegador. Puedes ver muchos proyectos aquí y todos dependen entre sí. Pero digamos que solo estoy trabajando en mi página de carrito en este momento. Puedo enfocarme en mi página de carrito y ver que estas son las únicas dependencias que tiene mi página de carrito separadas del resto. Y si no me importa realmente mi fecha de producto aquí, puedo excluir eso de la vista y ver una imagen aún más clara. También puedo agrupar las cosas por carpeta para ver dónde se encuentran las cosas dentro del repositorio y cosas así. Esto es realmente útil porque en el pasado, un arquitecto tendría que ir a una página de Wikipedia y actualizar con lo que cree que depende de qué y rápidamente se vuelve obsoleto.

Eso es todo el tiempo que tengo para mostrarte cosas en el código por ahora. Así que continuemos con la presentación. Puedes encontrar el repositorio del que te mostré ejemplos en narwhal/NX examples. Por favor, échale un vistazo, tiene una aplicación de coche escrita en React y las aplicaciones de producto están escritas en Angular. Así que puedes ver cómo se pueden usar múltiples frameworks en el mismo repositorio, pero aún así compartir código entre los dos sin problemas. Eso es todo por mi charla. Puedes seguirme en Twitter en Verzopandas y también asegúrate de visitar nx.dev, nx.app es para NX Cloud y síguenos en Twitter en nx DevTools. Muy bien. Muchas gracias y me encantaría responder tus preguntas ahora.

Eso estuvo genial. Muchas gracias, Jason, Gene, por esa charla. Fue excepcional. Y me recuerda, cuando trabajaba en IBM, teníamos muchos microservicios y nos llevó mucho tiempo implementar esas cosas y algo como Nx realmente nos hubiera sido útil.

Entonces, demos la bienvenida de nuevo a JJ. Gracias por venir. Tenemos algunas preguntas interesantes de la audiencia. Así que voy a empezar de inmediato.

La primera es realmente interesante para mí porque creo que es casi la parte más importante del desarrollo de software de la que no siempre hablamos, que es cómo convencer al liderazgo y a otras personas del equipo de hacer un cambio como este. Y más específicamente, ¿cómo convencer al liderazgo de que un monorepo no es un acoplamiento fuerte de código? Sí, creo que desde el punto de vista del liderazgo se verá mucha colaboración entre múltiples equipos. Y hay muchas dependencias entre diferentes equipos que crean fricción cuando no trabajan bien juntos, y un monorepo cambia drásticamente eso. Empresas como Facebook pueden colaborar entre múltiples equipos diferentes. Y de hecho, tenemos un case study con T-Mobile sobre cómo pudieron usar un monorepo e implementar su nueva tienda rápidamente, relativamente hablando. Y en cuanto al acoplamiento fuerte, tienes mucho código pero puedes hacer múltiples copias de ese código como Kent mencionó en su charla y cosas así. Así que aún puedes tener diferentes relaciones entre tu código y no necesariamente estar fuertemente acoplados.

De acuerdo. Otra gran pregunta aquí es, si comienzas a usar NX, ¿qué tan dependiente se vuelve la base de código de NX? Si decides más tarde que quieres dejar de usarlo, ¿es algo de lo que puedes migrar fácilmente? Sí, NX es una herramienta de desarrollo, ¿verdad? Así que no tiene nada que ver con tu código de producción. Y las cosas que están bajo NX, aunque son muy inteligentes y las tenemos disponibles para todos, puedes hacerlo tú mismo, ¿verdad? O puedes usar otra herramienta que también funcione con esto. Entonces, empresas como Facebook no usan NX internamente, pero tienen sus propias herramientas. Creo que se llama Pants o Buck, una de ellas, ¿verdad? Y hace cosas muy similares, pero es mucho más difícil de configurar. Pero sí, si algún día decides que NX no funciona para ti y necesitas algo más, entonces puedes dejar de usarlo. No cambia la forma en que escribes tu código, solo trabaja en torno a él. Así que sí.

A ver. ¿NX admite la implementación en diferentes entornos, como si quisieras implementar en Heroku? Sí, NX admite... Cada proyecto puede implementarse de manera diferente según lo que necesiten. De hecho, hay un community plugin para Netlify y muchos otros servicios como Firebase. Así que es a nivel de proyecto. Si quieres implementar una API de esta manera, quieres implementar un front-end de otra manera, otro front-end de otra manera, tienes libertad total. Una pregunta que vi y que me gustó mucho es cómo podrían trabajar juntos los monorepos y los micro frontends. Sí, creo que hay una idea equivocada de que son mutuamente excluyentes y la gente habla de dividir su monolito en diferentes repositorios, pero puedes tener todos estos diferentes, los micro frontends son proyectos diferentes que este monorepo. Y de hecho, creo que el monorepo facilita la gestión de los micro frontends, ¿verdad? Porque cuando divides todo en frontends separados, cuando te asignan la tarea de cambiar como el encabezado universal en todos ellos, solo tienes este enorme trabajo repartido en diferentes repositorios y haciendo el mismo cambio varias veces.

Y con el monorepo, puedes hacer el cambio, hacer todas las correcciones de una vez y se actualizan todos los micro frontends, ¿verdad? Así que en realidad te has deshecho de ese gran obstáculo de trabajar en estos micro frontends al ponerlos en el mismo lugar. Y tengo una publicación en el blog al respecto. Así que puedes ver como los micro frontends de React son una combinación perfecta con los monorepos.

De acuerdo, sí. Así que una pregunta que veo aquí, la reformularé un poco para no señalar a nadie, pero si tienes un equipo donde el patrón ha sido crear un nuevo repositorio para cada cosa pequeña, ¿cuál es tu recomendación para ayudar a los equipos a trabajar dentro del marco de NX Monorepo cuando ese ha sido el patrón anterior de dividir todo en pequeñas bases de código? Sí, y supongo que a medida que divides el código en pequeñas bases de código, también las publicas en un registro en algún lugar para que las personas puedan descargarlas. Creo que lo primero que haría es mover las partes publicables a NX y luego tener los diferentes proyectos dentro de NX y puedes ver las relaciones entre ellos, pero luego puedes publicarlos de nuevo, ya sabes, en artifactory, o cualquier otro registro, y luego puedes comenzar a incorporarlos desde nodos más altos de tu gráfico de dependencias.

Mm-hmm. Entonces, una pregunta que tengo es ¿cuál es la diferencia entre algo como NX y otras herramientas de gestión de monorepos como Lerna? ¿Son lo mismo o resuelven problemas diferentes? Sí, Lerna es muy popular y es realmente bueno, creo, para la gestión de paquetes. Entonces, NX tiene muchos paquetes diferentes que gestionamos y no usamos Lerna, pero sería bueno tener algo que simplemente ejecute todo, y eso es lo que hace Lerna. Te permite tener proyectos separados, pero te permite ejecutar compilaciones en todos ellos, probarlos a todos. Pero al final de mi charla estaba hablando de cómo, ya sabes, ejecutar todo llevará mucho tiempo una vez que llegues a la escala de cinco o seis equipos diferentes. Entonces, cuando hablas de organizaciones como Facebook, ejecutar todas las pruebas lleva mucho tiempo. Así que NX tiene la inteligencia, junto con eso, para poder ejecutar solo una parte de tus proyectos cuando sea necesario para verificar que el cambio sea seguro para la producción.

Entendido. Entonces, eso se relaciona con otra pregunta aquí, que es cómo se admite a los equipos grandes que trabajan en un solo repositorio si se necesita algo como una cola de fusión. Puede que no esté tan familiarizado con el término de cola de fusión, pero tal vez sea como, ya sabes, muchas personas trabajando en el mismo monorepo, podrías imaginar muchos conflictos de fusión, ¿verdad? Creo que también es una idea equivocada porque los conflictos de fusión solo ocurren cuando dos personas trabajan en lo mismo. Y no es exactamente como, ya sabes, mil personas trabajando en el mismo fragmento de código, ¿verdad? Todos están trabajando en su pequeña parte del monorepo. Así que muchas veces no tendrás conflictos de fusión, ¿verdad?, porque estás trabajando en algo completamente diferente a otras personas. Lo único es cuando estás trabajando en un cambio que afecta a todo el monorepo, digamos, como cambiar algo muy importante, entonces sí, habrá conflictos de fusión cuando las personas fusionen su código. Pero bueno, solo tendrás que hacerlo una vez en lugar de hacerlo 50 veces diferentes en todos esos equipos diferentes. Entonces, al final del día, sigue siendo más eficiente desde el punto de vista del flujo de trabajo, ¿verdad?, y sí, la única otra recomendación que tengo es que tal vez necesites esto, ya sabes, necesito este cambio, déjame simplemente forzarlo sin obtener todas mis aprobaciones o como, hay un equipo separado que maneja ese tipo de cambio. Así es como recomendaría hacerlo. No estoy seguro si entendí correctamente la cola de fusión. Entonces, la pregunta ha sido reformulada para hablar sobre una cola de implementación. Y bueno, voy a hablar sobre mi propia experiencia porque sé con certeza lo que estoy preguntando, solo para asegurarme. Y lo que he visto es que en muchas empresas, cuando estás listo para implementar algo en particular, digamos que el frontend de la aplicación está a punto de implementar algo. Puede haber múltiples ramas en marcha, pero bloquearán la implementación durante un período de tiempo para asegurarse de que el código se fusione y se implemente correctamente. El flujo de trabajo que usamos ahora no funcionaría en un monorepo porque estaríamos bloqueando a toda la empresa. La mayoría de ese código no se ve afectado por la implementación del frontend. Entonces, ¿cómo funciona un flujo de trabajo así, donde necesito decir, nadie puede fusionar en la interfaz de usuario durante este período de tiempo, cómo funcionaría eso? Sí, el flujo de trabajo de desarrollo que funciona muy bien con monorepos es un desarrollo basado en tronco. Eso significa que todos desarrollan en función de la rama principal o de desarrollo, pero todos los commits van allí.

Cuando llega el momento de hacer lanzamientos, y como mencioné, puedes lanzar una aplicación separada por sí misma. No tienes que lanzar todo el monorepo a la vez. Entonces, lo que puedes hacer es cortar una rama de lanzamiento basada en master, ¿verdad? Y digamos que es un lanzamiento para el 17 de abril. No lances en un viernes, pero digamos que has cortado esta rama de lanzamiento, la despliegas en un entorno de QA, un entorno de staging, lo que sea, ¿verdad? Realizas esas pruebas, y luego despliegas en base a esa rama, ¿verdad? Mientras tanto, master sigue avanzando, pero no tienes que preocuparte, ¿verdad? Todos siguen trabajando en ello, ¿verdad? Y cosas así. Y luego, cuando otro equipo quiera hacer su propio despliegue, pueden cortar una rama desde master, ¿verdad? Y luego usarla para el lanzamiento. Así que recomiendo investigar el desarrollo basado en tronco y lo que eso significa. Funciona de la mano con los monorepos. Es una gran pregunta. Genial. Y eso es todo el tiempo que tenemos. JJ, muchas gracias por la charla. Gracias por acompañarnos y responder preguntas. Y recuerden, si tienen un boleto pagado, JJ está a punto de ir a una sala especial donde pueden tener tiempo con él. Así que asegúrense de revisar los detalles de su boleto y unirse si tienen preguntas adicionales. ...