Escalando el Desarrollo de React con Nx

Muy bien, estoy muy emocionado de estar aquí hoy y poder hablarles sobre el desarrollo de Schedule React específicamente con NX. Antes de comenzar, permítanme presentarme. Mi nombre es Jurijs Tromfloner. Soy un Experto en Desarrollo de Google en tecnologías web. También soy instructor en AgCat y Embajador de Cypress.

En este momento, trabajo en Nowll como arquitecto de JavaScript y gerente de ingeniería, y en Nowll tratamos de ayudar a los equipos a aprender, crecer y tener éxito. Y lo hacemos ayudando a planificar sus hojas de ruta, identificar restricciones técnicas. También brindamos capacitaciones en talleres, por ejemplo, en conferencias, o charlas en conferencias, como la que estoy haciendo ahora. Sin embargo, lo que prefiero es trabajar como parte integrada de tu equipo, donde podemos identificar las cosas a medida que surgen.

Entonces, ¿cómo escalamos el desarrollo, especialmente con equipos grandes, y específicamente desde una perspectiva técnica, puramente? Y así identifico básicamente esos tres pilares, básicamente impulsar y automatizar una buena arquitectura, luego también tener herramientas modernas a mano, y una mejor experiencia de desarrollo hará que nuestros desarrolladores sean más productivos. Y finalmente, la velocidad en general. Y me gustaría hablar principalmente sobre Annex hoy, que es nuestra herramienta de desarrollo de código abierto, diseñada para Monorepos, pero también funciona sin Monorepos, de hecho, muy bien.

Entonces, esta es básicamente la estructura que generalmente obtienes cuando generas un nuevo proyecto, ¿verdad? Entonces, lo que llamo esto es como una estructura monolítica, tienes esa aplicación, tienes diferentes tipos de carpetas, donde cada una de esas carpetas representa una funcionalidad y un límite de características, generalmente. Ahora, con Annex es un poco diferente, allí tenemos los bloques de construcción de aplicaciones y bibliotecas. Ahora, la aplicación, como puedes ver aquí, se encuentra en la parte superior, y luego están las bibliotecas individuales allí abajo. Y la razón de esto es que conduce a una mejor arquitectura en general, porque las bibliotecas representan un límite mucho más fuerte que solo las carpetas. Con las carpetas, es muy difícil controlar lo que se puede exportar y también señalar lo que otros desarrolladores pueden exportar. Y así, en Annex, lo que tienes generalmente es una aplicación muy delgada en la parte superior, y luego tienes muchas de esas bibliotecas de espacio de trabajo bien definidas, donde se encuentra la lógica real. Y esas bibliotecas de espacio de trabajo realmente no necesitan ser publicadas en ningún lugar, pueden, pero pueden vivir dentro del espacio de trabajo y la aplicación simplemente las enlaza. Y así, al final, la aplicación, si quieres, es realmente solo la que se puede implementar. Y luego la lógica está realmente en esas bibliotecas. Y lo que a menudo sucede a partir de esa situación, es que las personas comienzan a crear varias de esas aplicaciones y simplemente eligen las bibliotecas que realmente necesitan. Y esto, por ejemplo, te permite implementar la misma infraestructura varias veces e incluso escalarla de diferentes formas. Por ejemplo, es posible que deseemos escalar más la parte de fases públicas que tal vez esa parte administrativa, que solo es utilizada por usuarios internos. Pero hoy realmente me gustaría ser más práctico y mostrarte cómo es trabajar con Annex. Y para comenzar, por supuesto, simplemente instalas el espacio de trabajo de Annex y esto se hace mediante create Annex workspace, le das un nombre, digamos react-summit. Y también paso aquí un administrador de paquetes, que en este caso es Yarn, pero también podría ser pnpm o npm. Y esto ahora instala el espacio de trabajo de Annex básicamente configurado y allí se nos hacen algunas preguntas. Entonces podemos comenzar con un espacio de trabajo vacío, pero también podemos usar uno de esos preajustes que son bastante útiles, ya que ya están preconfigurados. Y así elegimos react y podemos darle un nombre, por ejemplo, demo app.

Y ahora tenemos un par de preguntas más, como qué tipo de estilos queremos usar, y así sucesivamente. Ahora, voy a interrumpir esto aquí, porque ya lo he hecho y quiero ahorrar tiempo de instalación de npm.

Así es como se ve un espacio de trabajo generado. Puedes ver las carpetas de aplicaciones y bibliotecas, de las que mencioné antes. De hecho, si abro esto, ya tenemos la aplicación de cursos generada para nosotros cuando configuramos ese espacio de trabajo. Es una aplicación de react. Y también tenemos esa configuración de prueba de extremo a extremo para nosotros, que en este caso está basada en cypress y ya está configurada para probar nuestra aplicación de cursos. La carpeta de bibliotecas todavía está vacía.

Para comenzar, puedo simplemente hacer yarn start o el equivalente de nx sería nx serve y courses, que es mi aplicación de cursos. Luego, si voy a localhost 4200, puedo ver la aplicación siendo servida una vez que se compile y se inicie. Y aquí está, mi bienvenida a la aplicación de cursos. Ahora, en este momento, no tengo ninguna biblioteca. Y ese es otro punto muy fuerte de nx, tiene esos generadores. Y así, lo que puedo hacer es escribir nx generate o g para generar. Ahora estamos en react, que es el complemento y luego biblioteca para la biblioteca que queremos ejecutar. Y llamémosla course item, que es nuestra biblioteca que queremos generar. Y aquí podría proporcionar más opciones para personalizar la generación. Pero por ahora, vamos con los valores predeterminados.

Y lo que ves aquí ahora es que se genera esa biblioteca course item para nosotros, que tiene esta estructura, son archivos de configuración. Luego hay una carpeta de origen, que tiene el archivo index TS aquí, que es como la API pública. Y aquí es lo que realmente quieres exportar para que otros lo consuman mientras que todo lo que está dentro de esa carpeta lib aquí es privado solo para esa biblioteca. Y también tenemos aquí componentes prácticos ya generados para nosotros. Ahora, la parte muy interesante aquí es que en el mapeo de ruta tsconfig-base aquí en el archivo de configuración, ya tenemos configurado un mapeo de tipo a ruta. Y esto nos permite importar fácilmente una biblioteca en nuestras aplicaciones sin tener que usar esa ruta fija de la ruta relativa hacia ellas. Así que voy a ir a los cursos aquí. Abramos aquí el archivo apt TSX. Y eliminemos toda esa parte aquí que realmente no necesitamos por ahora. Y lo que quiero hacer aquí es importar nuestra course item. Y así puedes ver, puedo importarlo con ese prefijo aquí, que acabamos de ver antes. Así que realmente parece como si esta fuera una biblioteca publicable, pero en realidad solo está enlazada.

La otra parte interesante también es que NX realiza un seguimiento interno de las dependencias y de cómo se relacionan entre sí. Así que puedo usar aquí el comando de gráfico de profundidad para visualizar esas dependencias que NX tiene internamente. Y aquí, por ejemplo, esta es la situación actual que tenemos. Tenemos la aplicación de cursos, luego tenemos una dependencia implícita en esa parte de pruebas de extremo a extremo que prueba nuestra aplicación de cursos, y luego tenemos la biblioteca de elementos de curso que utiliza la aplicación de cursos. Esto es muy útil especialmente a medida que nuestro espacio de trabajo crece, así que exploremos eso.

Lo que podríamos hacer, por ejemplo, es crear una aplicación Next.js pública. Para hacer eso, podemos instalar un nuevo complemento de Next. Y por cierto, estos son complementos que ya proporcionamos, pero hay toneladas de complementos de la comunidad para una variedad de casos de uso, así que definitivamente revisa esos también. Ahora que tenemos Next instalado, podemos generar la aplicación. Nuevamente, podría usar la línea de comandos, pero a veces es más práctico usar el complemento NX Console Visual Studio Code. Eso me permite ejecutar la generación aquí, y vemos todos los generadores posibles aquí. Y quiero ir con el nuevo Next para generar una aplicación Next. Llamémosla 'public'. Y aquí el estilo puede permanecer igual. Todavía queremos una prueba de Cypress. Ejecutor de JS, ESLint y también JS para testing. Y aquí abajo, puedes ver una vista previa de lo que realmente se ejecutaría cada vez que ejecuto un comando. Así que también podemos aprender sobre los nuevos comandos aquí abajo. Así que simplemente ejecutemos esto. Generará mi nueva aplicación, y mientras se instala, vamos aquí y exploremos lo que se genera. Tenemos la aplicación de cursos, y ahora puedes ver que también tenemos esa aplicación pública. Esta es una aplicación Next.js. Aquí vemos las páginas. Por ejemplo, vayamos a la página de índice aquí. Y nuevamente, eliminemos aquí todas esas cosas que realmente no necesitamos. Y haremos lo mismo aquí para insertar básicamente nuestro elemento de curso. Entonces, nuevamente, lo importé de la misma manera como una referencia dentro de una aplicación Next.js.

Entonces, ahora iniciemos nuestra aplicación Next.js. Ejecutamos 'yarn serve public', que es nuestra aplicación Next. También puedes ver la uniformidad de los comandos. Siempre son los mismos, independientemente de si usas una configuración de React, una configuración de backend de Node o una aplicación Next.js, lo cual es muy importante en términos de aprendizaje que el equipo debe hacer a medida que crece.

Ahora puedes ver que la aplicación pública se está ejecutando. Esta es nuestra aplicación Next, que también utiliza ese elemento de curso. De hecho, podríamos explorar el gráfico de dependencias nuevamente. Si ejecuto 'Next.dev graph', podemos iniciarlo aquí. Ahora la situación se ve bastante diferente porque ahora tenemos la aplicación de cursos y la aplicación pública. Ambas tienen sus pruebas de extremo a extremo y ambas hacen referencia al elemento de curso.

Generemos un par de bibliotecas más para ver cómo evoluciona el gráfico de dependencias. Nuevamente, estoy usando la consola NX. No quiero generar solo una biblioteca de espacio de trabajo. Llamémosla 'core', que no es específica de ningún framework en particular. Por lo tanto, podría compartirse entre frameworks o incluso entre un backend y un frontend. Ahora tenemos generada esa biblioteca 'core' del curso. También quiero generar una nueva biblioteca, que esta vez es una biblioteca de React, y la llamo 'coupons'. Esta vez quiero estructurarla en un directorio de administración porque será una biblioteca que quiero usar desde la parte de administración de la aplicación. Luego quiero tener otra, que es 'sales', que es la que quiero usar nuevamente dentro del directorio de administración. Bien, si cerramos esto y reducimos un poco la ventana, ahora podemos ver que tenemos en la carpeta de bibliotecas esas bibliotecas de administración, 'coupons' y 'sales', que son bibliotecas, y la biblioteca 'core'. Si volvemos a utilizar el gráfico de dependencias, veremos que la estructura cambió un poco nuevamente porque ahora tenemos las bibliotecas, las aplicaciones que hacen referencia a esa biblioteca de elementos de curso, pero luego tenemos esas tres bibliotecas que están allí, pero aún no están conectadas.

Hagamos eso. Vamos aquí a la aplicación. Primero, vayamos a la parte de 'coupons' y hagamos referencia a nuestra biblioteca 'core' aquí. Importaremos 'core' y lo llamaremos aquí. Lo mismo haremos para 'sales', lo referenciaremos aquí también. Y finalmente, vamos aquí a la aplicación de cursos y la referenciamos desde nuestra aplicación. Ahora están conectadas. Podemos ir aquí y nuevamente iniciar el gráfico de dependencias. Ahora deberíamos ver conexiones reales entre todas esas bibliotecas. Ahora vemos que la aplicación de cursos hace referencia a 'admin coupons', 'admin sales', 'core' y la parte pública y la parte de cursos comparten ese elemento de curso allí abajo.

Ahora esto ya es una configuración muy buena. En algún momento, sin embargo, a medida que tu espacio de trabajo crece, es posible que desees imponer restricciones. Por ejemplo, no quieres que la parte pública importe la biblioteca de ventas de administración. Y a medida que tu espacio de trabajo crece, esto se vuelve realmente importante.

Entonces, a continuación, hay una forma de imponer esas restricciones. Primero, lo que debes hacer es asignar tipos a esas bibliotecas y aplicaciones. Podemos ir aquí a la configuración NxJSON y comenzar a asignar tipos. Estas son solo cadenas arbitrarias, por lo que realmente puedes definirlas como desees. Por lo general, uso un prefijo y un sufijo aquí. Por ejemplo, para las aplicaciones, simplemente les doy el tipo 'application'. Luego, defino el tipo 'feature', que es para nuestras bibliotecas de administración de cupones, ventas y elementos de cursos, que representan una característica encapsulada dentro de nuestro espacio de trabajo. Luego tengo un tipo 'utility', que es para el núcleo, que es algo que se puede compartir entre varias bibliotecas, como funcionalidad de utilidad general. También puedo asignar alcances. Por ejemplo, tengo una etiqueta adicional llamada 'scope', que llamo 'admin' para todas las partes relacionadas con la administración aquí arriba. Lo mismo para el alcance 'public' para todas las partes públicas aquí abajo. Y finalmente, también tendremos algo que se comparte, como por ejemplo, el elemento de curso y las partes del núcleo que se comparten realmente. Les asigno la etiqueta 'shared' aquí.

Ahora necesitamos imponer las restricciones y podemos hacerlo a través del linting. Si vamos al archivo eslintrc, aquí tenemos las reglas de imposición de límites de módulo que proporciona NX. Como puedes ver, puedes definir las restricciones. Por ejemplo, podemos decir que una biblioteca del tipo 'utility' solo puede hacer referencia a un tipo 'utility'. No queremos que una biblioteca de utilidades haga referencia a una biblioteca de características, sino al revés, ¿verdad? Las bibliotecas de características pueden importar utilidades. Luego podemos definir una vez la característica. Entonces, el tipo 'feature' puede hacer referencia a características y utilidades. Luego, para los alcances, podemos decir que el alcance 'admin' solo puede hacer referencia al alcance 'admin'. Y finalmente, el alcance 'public' solo puede hacer referencia al alcance 'public'. De esta manera, separamos los diferentes alcances de nuestro espacio de trabajo. Obviamente, también necesitamos agregar algunos alcances compartidos aquí, porque el elemento de curso y la utilidad del núcleo en general pueden ser compartidos entre esos diferentes alcances dentro de nuestro espacio de trabajo.

Entonces, ¿cómo podemos probar eso? Con el linting en realidad. Y ahora rompamos la regla. Vamos a nuestra aplicación Next.js aquí arriba. Vamos a entrar en el archivo index.ts y vamos a importar el admin sales. Ahora hemos creado básicamente una conexión desde public a admin sales lo cual está prohibido por las reglas de linting. Y ahora si ejecuto NX lint public que es nuestra aplicación Next.js pública, inicia el linting. Y lo que verás ahora es un error básicamente en nuestro archivo index.ts que dice que un proyecto etiquetado con el alcance public solo puede depender realmente de bibliotecas etiquetadas con el alcance public o alcance shared. También lo verás directamente en el editor. A veces Visual Studio es un poco lento para actualizar los alcances una vez que los defines pero también lo verías directamente aquí. Y esto obviamente es una gran ventaja y déjame en realidad eliminar eso para que nuestro linting funcione de nuevo. Esto es una gran ventaja porque te permite controlar tu arquitectura a medida que crece.

La siguiente parte es, obviamente, la velocidad. A medida que creces y quieres escalar tu espacio de trabajo, no puedes construir todo cada vez, ¿verdad? Si cambias algo aquí abajo, no puedes simplemente construir todo lo que está conectado a él. Entonces, Nx tiene un comando llamado 'affected', pero primero permíteme confirmar todas estas partes y simulemos que estamos desarrollando una función.

Así que creemos una nueva rama, mi función y ahora aquí voy a hacer un cambio digamos en la biblioteca de elementos del curso. Así que vamos aquí a elementos del curso y digamos simplemente bienvenido a elementos del curso, así. Hicimos un cambio y ahora Nx puede usar el gráfico de dependencias para averiguar qué necesita volver a probar y volver a construir. Y eso se puede hacer mediante el comando llamado 'affected' de Nx y también podemos aplicarlo al gráfico de profundidad. Si digo 'affected depth graph', ahora puedes ver una subsección del gráfico que se vería afectada por los comandos. También podemos ver todos ellos. Los veo coloreados de manera un poco diferente. Obviamente, Nx determina que si este cambia, no necesita construir ni probar este, sino solo las rutas que van hacia arriba. Y así, de hecho, si echamos un vistazo aquí y ejecuto 'yarn Nx affected test', solo ejecutará realmente estas tres bibliotecas y ejecutará las pruebas para ellas.

La parte interesante también es que, si vuelvo a ejecutar esto, hay otro concepto que mejora la velocidad, que es nuestra caché. Así que si vuelvo a ejecutar esto, verás que es inmediato, porque los tres proyectos se tomaron de la caché. Ahora, esta caché por defecto solo se almacena localmente. Entonces, en la carpeta de módulos de nodo 'cache.nx', está la caché en realidad, que determina qué necesita reconstruir. Pero puedes distribuir eso y puedes ir directamente, por ejemplo, a Nx Cloud. Si voy a Nx.app, puedes conectar el espacio de trabajo y simplemente hago clic aquí una vez que haya iniciado sesión para conectar el espacio de trabajo. No tengo Nx Cloud. Así que solo estoy usando el comando aquí para instalarlo ya que estoy usando Yarn. Esto es lo que estaría usando. Así que déjame pegarlo aquí y luego ejecutarlo. Ahora instala la biblioteca de Nx Cloud. y la configura directamente para mí. Y ahora, si vuelvo a ejecutar el 'affected test', ahora probará todas las bibliotecas que están en mi espacio de trabajo.

De acuerdo, hemos cambiado algunas infraestructuras fundamentales aquí como algunas bibliotecas de configuración básica. Entonces, Nx necesita probar todo de nuevo porque podríamos haber instalado un paquete, ¿verdad? Y una vez que se haya instalado, en realidad podría simular como si fuera un compañero de trabajo, ¿verdad? Algunos de mis compañeros de trabajo ya ejecutaron esto el día anterior, la caché se distribuye en Nx Cloud. Así que voy a borrar esa caché y volver a ejecutarlo de nuevo. Y ahora puedes ver que la ejecución es básicamente inmediata, porque todos los productos se obtuvieron de la caché del mundo real. También obtienes una vista agradable, más información basada en Nx Cloud sobre la vista, qué se construyó, si fue un acierto de caché o no, y mucho más. Entonces, lo que cubrimos básicamente es cómo las aplicaciones y las bibliotecas diferencian a Nx de los espacios de trabajo tradicionales, cómo puedes definir reglas de límites para mejorar esa arquitectura y básicamente protegerte contra algunas referencias enredadas, también cómo puedes visualizar las dependencias con el gráfico de dependencias, las capacidades de generación de los generadores de Nx, que son muy potentes, es como si ya tuvieras generadores que no pudiste mostrar debido a la limitación de tiempo, como configuraciones para Cypress, como configuraciones para Cypress para Just, para Storybook que genera automáticamente tus historias a partir de tus componentes y mucho más.

Y finalmente, obviamente, tus mejoras de velocidad a través de los comandos afectados y también el almacenamiento en caché distribuido por Nx Cloud. Pero como mencioné, realmente solo hemos rascado la superficie, ¿verdad? Hay mucho más por explorar. Estos son algunos de los datos principales que puedes usar, como nuestro sitio web nx.dev, la aplicación Nx para la parte de Nx Cloud. Y por cierto, para Nx Cloud, siempre puedes comenzar con él. Es completamente gratuito, no tienes que usar ninguna tarjeta de crédito para obtener cinco horas al mes de forma gratuita. Y luego, obviamente, puedes optar por pagar más si te gusta el producto. También tenemos nuestro canal de YouTube Nowrl, los videos oficiales de nuestro canal de YouTube Nowrl y también un curso de Acai que es completamente gratuito, que puedes usar para profundizar más en los detalles de cómo funciona Nx.

Para comenzar, nuevamente, usa NPX, CreateNx Workspace para configurar un nuevo espacio de trabajo fresco. Eso obviamente te brinda más beneficios, pero si solo quieres probarlo, especialmente si estás interesado en las capacidades de almacenamiento en caché de Nx, también puedes usar NPX add Nx a Monorepo para comenzar. Y convertirá, por ejemplo, un espacio de trabajo existente de Yarn y lo mejorará con las capacidades de Nx. Y aquí hay un par de enlaces que explican básicamente cómo funciona. Y también, por ejemplo, convertimos un repositorio de Storybook y también el repositorio de Reemotion. Así que definitivamente échales un vistazo.

Gracias por tu atención. Y si tienes alguna pregunta, no dudes en conectarte conmigo en Twitter. Envíame tus preguntas en Twitter y nos conectamos allí. Gracias. Yuri preguntó a las personas si están utilizando un Monorepo en su proyecto en este momento. Así que veamos los resultados. Tengo que cambiar de pantalla aquí. Sí, y estoy contento con eso. Tiene un 32%. Y no, y no creo que necesite uno, es el segundo con un 19%. Y el tercero es Monorepo con un 19%. Entonces, Yuri, ¿esto es lo que esperabas? Sí, es bastante interesante verlo. Y creo que la contribución es más o menos lo que esperaba. Sí, yo mismo también estoy usando un Monorepo, pero también estoy trabajando en un proyecto pequeño. Entonces, sigue siendo un Monorepo, ¿verdad? ¿Cuenta eso? Sí, absolutamente. Por eso también hice esta pregunta. Porque a veces la gente piensa que un Monorepo es solo para proyectos grandes y de enterprise, pero no necesariamente es el caso, ¿verdad? Incluso puedes tener tu proyecto de open-source con un par de bibliotecas y una aplicación de demostración y aún así sería un Monorepo, ¿verdad? Dependiendo de cómo quieras estructurarlo.

Genial. Ahora vamos a pasar a las preguntas de nuestra audiencia. Y la primera es, Voy a intentar pronunciar este nombre de usuario, Soshikropka. ¿Qué tan sencillo es integrar NX en un Monorepo existente y grande? Entonces, adaptar NX a un Monorepo existente. ¿Podemos hacer eso? Sí, hay algunas posibilidades para hacerlo. Como mencioné en mi charla, está el comando nx-add-to-monorepo, como el comando npx-add-to-monorepo, donde básicamente estamos agregando, especialmente en los espacios de trabajo de Yarn, una configuración mínima, que te brindaría algunos de los beneficios de NX, como por ejemplo, la caché de cálculos, la ejecución de tareas en paralelo y cosas así. Básicamente, la organización de la ejecución de los scripts de Node, que podrías tener en ese espacio de trabajo de Yarn. Pero obviamente, si quieres tener una experiencia más completa, como con los generadores, y eso es lo que define la experiencia de NX, entonces obviamente, es mejor configurar un nuevo Monorepo y migrar los productos uno por uno.

De acuerdo. También tenemos algunos scripts npx, por ejemplo, para migrar una aplicación React a un Monorepo NX, lo que te ayudará a realizar modificaciones de código y fusionarlas en un repositorio NX. Así que definitivamente hay algunas posibilidades y estamos trabajando, por supuesto, para hacerlo aún más fácil.

Genial. Y tal vez, Suresh Kropak, puedo darle algunos consejos sobre lo que necesita en su chat espacial. La siguiente pregunta es de Thiago elfs. ¿Qué tan difícil es integrar pruebas de extremo a extremo con otras estructuras como el uso de OAuth? ¿Qué fue lo último? Me perdí la última parte, ¿pruebas de extremo a extremo? Uso de OAuth. Bueno, eso depende de cómo funcionen tus llamadas OAuth. Por ejemplo, la configuración predeterminada al generar una nueva aplicación dentro de NX es que obtienes una prueba de Cypress y una configuración de Cypress junto con tu aplicación. Y realmente depende de cómo Cypress maneje eso. Cypress tiene algunas capacidades de simulación donde puedes simular esas llamadas o dejar que pasen en un entorno de desarrollo donde conoces los usuarios que tienes y puedes simular escenarios de extremo a extremo más realistas. Pero dicho esto, muchos de los escenarios que vemos cuando trabajamos en monorepos también son simulados. Por lo tanto, no es realmente una prueba de extremo a extremo completa en el sentido de que accedes a una base de datos y vuelves, porque tienden a ser inestables. Por lo general, nuestros usuarios tienen una configuración de Cypress que simula algunas de esas API críticas, como la autenticación, por ejemplo. Y luego básicamente tienen algunas pruebas de integración local en su configuración de front-end. Pero Cypress tiene algunas guías bastante buenas sobre cómo integrarse con escenarios de OAuth y en general con escenarios de autenticación. Así que eso no depende realmente de NX, sino más bien de cómo trabajar con OAuth y Cypress, sí.

De acuerdo, la siguiente pregunta es de Vasily Shalkov. Tienes estas múltiples aplicaciones creadas por NX. Normalmente, el despliegue y desarrollo de nuestras aplicaciones son independientes. ¿NX no tiene herramientas para ayudar con CI/CD y aún así obtener los beneficios de entregar aplicaciones de forma independiente? Sí, claro, al final, cada una de esas aplicaciones en el Monorepo vive por sí misma, básicamente. Simplemente que las bibliotecas permiten compartir código con otras. Y así siempre puedes desplegar la aplicación individual. Ahora bien, realmente no tenemos ninguna integración específica con la implementación de CI o CD. Tenemos algunos scripts de implementación, por ejemplo, para implementar en Vercel, en los que intentamos ayudar y optimizar. Pero al final, NX es una CLI que emite comandos. Y así, al final, puedes personalizarlo y adaptarlo a tus necesidades e incluso ampliarlo, como con tus comandos personalizados, agregar tu script de implementación personalizado para poder construir la aplicación, probarla, lo que sea, y luego implementarla en el entorno que necesites.

De acuerdo, genial. Tenemos una pregunta de Arik. ¿Existen capacidades para publicar versiones/bibliotecas? Sí.

Entonces, si entiendo correctamente la pregunta, como te imaginas, como bibliotecas publicables, como en NX, normalmente lo que tienes es la configuración predeterminada simplemente genera las llamadas bibliotecas del espacio de trabajo. No están destinadas a ser publicadas en ningún NPM, pero puedes decidir qué tipo de biblioteca quieres. Tal vez quieras una que se integre solo con las aplicaciones que tienes, pero que también sea publicable para que otras personas la consuman fuera del monorepo, ¿verdad? Y en ese caso, puedes convertir una existente. Básicamente, hay generadores que te permiten convertir bibliotecas en una biblioteca publicable o cuando generas la biblioteca ya pasaste una marca de publicable, un alcance de NPM, y luego se configurará de tal manera que también puedas publicarla. Y al final, esa biblioteca se comportará de la misma manera que una aplicación. Puedes construir esa biblioteca. Tiene un objetivo de construcción. Así que terminará en una carpeta del disco. Y luego simplemente haces tu publicación de NPM allí y la publicas en algún registro.

Genial, de acuerdo. La siguiente pregunta es de Marvin. ¿Cuándo crees que NX introducirá una función de federación de módulos de Webpack 5? Lo estamos considerando. En este momento, no admitimos Webpack 5. Hay algunas restricciones de dependencias, pero definitivamente es algo que tenemos en nuestra lista para implementar en Webpack 5 y también brindar soporte. Algunas personas ya lo han implementado. Por lo tanto, puedes cambiar la dependencia, obviamente, y utilizar Webpack 5. Simplemente no lo admitimos de forma predeterminada y no podemos garantizar que todo funcione perfectamente. Pero tenemos algunos ejemplos de la comunidad que ya se han utilizado. Además, con pequeñas aplicaciones en las que se utilizan micro-frontends que comparten código en el Monorepo, pero se implementan como micro-frontends y federan el código entre ellos con Webpack 5.

Genial, eso suena poderoso. Y realmente genial que sea como, no quiero decir extensible, solo cambiable, sí, genial. Y la siguiente pregunta es de Mark C. ¿Cómo funcionaría la API de contexto de React con la carpeta lib? Bueno, al final, funcionaría de la misma manera que tendrías básicamente, cuando tienes esa funcionalidad específica dentro de la carpeta de la aplicación misma. La única distinción, como cuando mueves algo a la carpeta lib es que de alguna manera expones o encapsulas más la lógica que deseas exponer a la propia aplicación. Así que es más bien un patrón de composición. No es que la librería de alguna manera esté precompilada y solo consumes las fuentes compiladas, sino que en realidad la aplicación es una construcción de Webpack y simplemente consume desde esa posición, desde esa ubicación en la carpeta libs. Entonces, al final, no cambia realmente cuando lo tienes dentro de una carpeta de tu aplicación, pero dentro de la carpeta de tu librería, siempre está consumiendo eso desde la fuente.

Muy bien. La siguiente pregunta es de Ryan Burr, ¿hay una buena manera de gestionar todas tus etiquetas, alcance y dependencias en proyectos grandes? ¿Cómo lo haces? Sí, depende. Hay diferentes enfoques para gestionar eso. Por lo general, como mencioné y mostré en la charla, distinguimos entre alcances y tipos, ¿verdad? Con eso, también puedes tener una idea y restricciones entre tus aplicaciones. Pero también puedes ir más profundo, ¿verdad? Los alcances pueden definirse, son cadenas arbitrarias al final. Por lo que realmente puedes adaptarlos a un nivel granular o mantenerlos más generales, a un nivel más alto. El enfoque realmente depende de tu configuración de arquitectura. Hay muchas personas, por ejemplo, que utilizan un enfoque más orientado a dominios, donde cada librería, instrucción, subcarpetas, básicamente abarcan un dominio bien definido de todo tu espacio de trabajo. Y luego tienes librerías dedicadas, que son como la API pública para ese dominio, que luego tienen facetas, o algo que entra o básicamente expone la funcionalidad de ese dominio a otros dominios. Por lo que realmente puedes ir a un nivel de detalle muy alto. Por lo general, animo a las personas a utilizar etiquetas desde el principio. Y agregarlas más tarde es realmente difícil, porque tienes que hacer muchas correcciones, por supuesto. Pero luego comienza de forma sencilla, y simplemente extiende las etiquetas a medida que avanzas.

Sí. Muy bien. Creo que esta es la última pregunta a la que tenemos tiempo para responder, y es de Imagine Wagons, buen nombre. ¿Cuál es el flujo de implementación y el pipeline de CI? Entonces, sí, la implementación, comencemos desde el pipeline de CI, tal vez el pipeline de CI simplemente construye lo que haya cambiado. Y eso es una de las partes más poderosas de NX, obviamente a medida que tu repositorio crece, los tiempos de construcción aumentarían y los tiempos de prueba aumentarían. Y así, NX tiene el comando 'affected'. Por lo que básicamente puedes enviar tu pull request o solicitud de fusión. Y en función del comentario que envíes allí, comparará qué cambios se han realizado con la rama base, que puede ser main o master, como desees usarlo. Y luego calcula qué ha cambiado, identifica las librerías y luego simplemente ejecuta las tareas, construye y limpia esas librerías. Y luego el pipeline de implementación es realmente muy similar. Entonces, si construiste la aplicación en esa ejecución específica de CI, simplemente obtienes un paquete distribuido, como un paquete compilado en esta carpeta, y desde allí lo recoges y luego lo implementas como lo harías normalmente. Por lo que no es necesario hacer ningún cambio allí.

Muy bien, Command Center, ¿tenemos tiempo para una pregunta más? Ah, lo siento, Yuri, tengo que interrumpirte. Lo siento. Yuri, muchas gracias por compartir esto con nosotros. Si alguien que está viendo aún quiere hacerle preguntas a Yuri, sé que hay muchas preguntas en Discord a las que no tuvimos la oportunidad de responder. Yuri estará en su sala de chat especial para los oradores. Así que asegúrate de ir allí si quieres unirte a la conversación, continuar la conversación con Yuri. Yuri, una vez más, muchas gracias y espero verte de nuevo pronto. Sí, gracias. Gracias por tenerme. Adiós. Adiós.