Remixando tu Stack en un Espacio de Trabajo Monorepo

Cómo Remix Tu Pila con ReactJS

Hola, hablemos de cómo podemos remix nuestra pila en un espacio de trabajo de Monorepo. Y me gustaría comenzar con una cita, o en realidad un tweet de Ryan Florens de hace un par de semanas, donde hizo una declaración bastante poderosa y menciona que sus archivos de enrutamiento deben configurar el enrutamiento para su pila específica. La implementación real de esa función que se visualiza allí, debe estar en otro lugar, ¿verdad? Entonces, lo importas, pero luego, dependiendo específicamente de la pila que tengas, configuras el enrutamiento y lo importas, y luego se agrupa y se visualiza en la página web.

Y este es un mecanismo muy poderoso para diseñar su sistema, pero también para organizar su código. Y podemos llevar esto aún más lejos. Normalmente, vemos exactamente este tipo de estructura, lo que Ryan Florence mencionó. Entonces tienes tu aplicación, tienes la carpeta de enrutamiento, que puede ser páginas, rutas, app, lo que sea. Y luego deberías tener, como menciona Ryan, una carpeta diferente potencialmente dentro de esa aplicación, que son tus funciones. Y luego tienes diferentes carpetas para todas esas funciones. Y el enrutamiento simplemente las importa.

Ahora podríamos ir un paso más allá e incluso moverlas fuera de la aplicación a una carpeta de paquetes dedicada. Entonces, esta nueva estructura, lo que ves ahora es que tenemos una carpeta de aplicaciones y ahora tenemos una carpeta de paquetes. Y en la carpeta de aplicaciones, todavía tenemos nuestra aplicación con su mecanismo de enrutamiento. Y luego, en la carpeta de paquetes, ahora tenemos diferentes carpetas para todas nuestras funciones. Y todas estas funciones ahora están independientes y encapsuladas de manera ordenada, y tienen un punto de API muy limpio donde hay un archivo index.ts que expone todo lo que se puede usar externamente y todo lo demás permanece dentro de ese paquete. Entonces, puedes imaginar que obtenemos una estructura muy limpia teniendo esta configuración aquí. Obviamente, podemos seguir adelante e importar como antes. Nuestra importación incluso podría parecer como si la consumiéramos de algún paquete externo como algún registro de MPM. Pero en realidad, solo se consume localmente en este caso. Pero puedes verlo aquí desde una declaración de importación.

Entonces, ¿cómo ayuda esto, en realidad? Bueno, potencialmente con algo como una migración incremental. Ahora, es posible que hayas notado que en mi ejemplo, usé una aplicación Next.js, ¿verdad? Está esa carpeta de páginas. Bueno, si usas las nuevas funciones o te unes a las nuevas funciones, es posible que tengas una carpeta de enrutamiento diferente allí. Pero esto no fue por accidente, sino que fue intencional. Entonces, es posible que hoy en día tengas una aplicación Next.js con algunas funciones ya incorporadas, con una aplicación que ya se ha desarrollado durante unos meses o incluso años. Y es posible que desees pasar lentamente a una pila de remix porque por alguna razón, eso es más adecuado para ti. Entonces, esto es exactamente lo que podrías lograr en esta configuración, porque como puedes ver, nuestra aplicación Next.js real y la función real ya están separadas y ordenadas. Y si prestas atención, esto ya es un Monorepo. Si quieres, ¿verdad? Solo tenemos una sola aplicación allí, pero tenemos una aplicación.

Tenemos un par de paquetes. Por lo tanto, esto es totalmente un monorepo, uno muy simple. Entonces, lo que podríamos hacer es simplemente agregar otra aplicación en ese caso. Por ejemplo, agregar una nueva aplicación de remix, que es nuestro destino de migración objetivo. Correcto. Donde queremos mover nuevas características o incluso mantenerlas dependiendo del caso de uso o estrategia de implementación.

Podríamos generar una nueva aplicación de remix con el comando create remix y luego agregar esa aplicación dentro de nuestro espacio de trabajo de monorepo e importar las características que ya tenemos. Puede haber algunas cosas específicas de características o incluso cosas que están acopladas a la aplicación Next.js, obviamente. Esas necesitan o podrían necesitar alguna refactorización. Pero es mucho más fácil porque ya se han movido.

Entonces, ¿cómo funciona esto en la práctica? Permítanme mostrarles. Pero primero, mi nombre es Juergen Stromflohner. Soy un experto desarrollador en tecnologías web. También soy instructor de ACAD. Y trabajo como director de experiencia de desarrollador para una herramienta llamada Annex. Annex es un sistema de compilación inteligente, rápido y extensible que funciona muy bien para configuraciones de monorepo y estructuras de aplicaciones que acabamos de discutir. Así que echemos un vistazo.

Tengo aquí mi aplicación Next con esa carpeta de características, que se importa directamente desde nuestra configuración de enrutamiento. Y esas características están organizadas de manera muy ordenada. Hay un archivo index.js que exporta nuestra funcionalidad, que es muy simple. Y luego también tenemos el sistema de diseño que exporta aquí un solo botón. Pero esto está organizado de la misma manera. ¿Cómo refactorizaríamos esto para obtener un espacio de trabajo de monorepo con una estructura más modular? Bueno, en primer lugar, probablemente seguiríamos adelante y crearíamos las carpetas. Y por cierto, esto depende completamente de usted, cómo nombre esto. El nombre normal que se encuentra es como aplicaciones y paquetes o Apps y Lips. Pero depende de usted cómo elija esos. Y probablemente seguiríamos adelante y moveríamos nuestra aplicación Next en este caso a esta carpeta de aplicaciones. Como siguiente paso, necesitamos separar estas características y moverlas a su carpeta de paquetes. Así que son completamente independientes. Y como resultado, ahora también deberíamos hacer que todas estas sean autónomas en el sentido de que tengan su propio paquete.

Sus propias dependencias, sus propios scripts de compilación y cosas así. Permítanme configurarlo rápidamente. Aquí vamos.

Ahora tenemos una carpeta de origen donde residen los archivos. Tenemos una configuración de compilación cercana aquí a la nuestra. Cada uno de estos paquetes ahora tiene su propio package.json con el script de compilación en este caso, y sus propias dependencias de desarrollo. Y la misma configuración se aplica también a ese paquete del sistema de design.

Ahora, el siguiente paso es configurar ese Monorepo para indicarle a NPM que cuando hagamos referencia a un paquete, lo haga localmente en lugar de globalmente. Para hacer eso, necesitamos un package.json a nivel de raíz aquí. Ese package.json es la configuración de nuestro Monorepo. Lo más importante es la propiedad del espacio de trabajo, que define cuáles son nuestras carpetas locales, dónde se deben vincular los paquetes entre sí. También puede tener algunas dependencias de desarrollo globales, así como dependencias que todos los paquetes del espacio de trabajo deben compartir entre sí.

Pero como siguiente paso, podemos continuar e instalar todas esas dependencias en la raíz del paquete. Con esto, ahora deberíamos poder vincular aquí nuestros paquetes a nuestra aplicación Next.js, porque obviamente nuestra importación anterior, como han visto aquí desde la carpeta de características local, ya no funciona porque esas características ya no existen. En su lugar, ahora deberíamos continuar y vincularlos a donde se han movido. Y así, en este caso, iría aquí para la característica de authentication e importarla desde aquí, mi org auth, así como aquí para esto, tendría aquí, mi org design system.

Pero también necesitamos hacer referencia a esas dependencias en nuestra aplicación Next.js. Así que iríamos aquí al package.json de nuestra aplicación Next.js en la carpeta de dependencias, y haríamos referencia aquí a mi org design system. Y podemos hacer referencia a ella con un asterisco porque no nos interesa una versión específica, aunque podríamos, pero preferimos consumir la última versión que se encuentra localmente aquí en nuestro espacio de trabajo. Y hacemos lo mismo para nuestra parte de autenticación.

Ahora instalemos las dependencias nuevamente para que npm pueda hacer la vinculación adecuada. Pero antes de poder consumirlas, también necesitamos compilar estos paquetes, porque obviamente dependen de la salida de compilación de convertir esto en un archivo JavaScript. Así que continuemos y construyamos eso. Podemos ejecutar npm run build y luego podemos darle la bandera de espacio de trabajo aquí y decir my org auth. Ahora deberíamos continuar y construir nuestra biblioteca de authentication. Y pueden ver aquí, produjo una carpeta dist, produjo archivos index DTS. Así que podemos hacer lo mismo aquí también para nuestra biblioteca del sistema de design. Entonces nuevamente ejecutamos la compilación y de manera similar obtendremos aquí una carpeta dist con los archivos compilados. Así que si ahora continuamos y ejecutamos nuestra aplicación Next.js.

Funcionaría perfectamente. Puedes ver aquí, obtenemos el nombre impreso, así como nuestro pequeño botón visualizado en la página web. Entonces, es posible que hayas notado que hay algunas cosas en la configuración que no son ideales, especialmente en términos de la experiencia de desarrollo (DX). Porque, por ejemplo, cada vez que ejecutamos nuestra aplicación Next.js, necesitamos asegurarnos siempre de que ya se haya realizado una compilación para nuestros paquetes de autenticación ydesign sistema de diseño. Por lo tanto, necesitamos tener esa carpeta dist ya existente porque nuestra aplicación Next depende de esas salidas de compilación. Y de manera similar, también, si realizamos algún cambio en esas carpetas de paquetes, necesitamos algún proceso de observación que actualice la aplicación actual.

Ahora, agregar una X, por ejemplo, puede ayudar con algunas de estas cosas. Así que hagámoslo. Agregar una X es bastante sencillo. Ejecute el comando npx nx at latest y ejecute un script init. Lo que hará es agregar el paquete nx a este espacio de trabajo de Monorepo. Luego, se le harán algunas preguntas para configurarlo. En primer lugar, la primera pregunta es exactamente lo que mencioné antes. ¿Hay algún script que deba ejecutarse en orden? Nuestro script de compilación, como mencionamos anteriormente, definitivamente debe ejecutarse en orden porque necesitamos ejecutar primero las dependencias. De manera similar, una X tiene una función de almacenamiento en caché. Entonces pregunta qué scripts se pueden almacenar en caché. Def y start, probablemente no porque eso se trata realmente del desarrollo, pero build, def y potencialmente si tuviéramos scripts de prueba o linting, también se podrían almacenar en caché. Así que seleccionemos build aquí. Incluso podríamos personalizar la carpeta de salida si hay alguna, pero lo más común es que esta build, publish, public ya estén cubiertas y también si queremos habilitar el almacenamiento en caché distribuido. Así que definitivamente podemos optar por instalarlo. Ahora, lo que tenemos aquí en esta configuración es un nuevo archivo NxJSON. En primer lugar, hay una nueva dependencia con una X aquí en nuestro archivo package.json en la raíz. También tenemos este paquete NxCloud porque optamos por el almacenamiento en caché distribuido. Y la parte más interesante aquí es ese archivo NxJSON, que tiene las operaciones almacenables en caché definidas y el objetivo predeterminado también. Esto es exactamente el tipo de operación del que hablé antes, que se asegura de que cuando ejecutamos la compilación de algún paquete o aplicación, se ejecute primero la compilación de todos sus hijos y luego la compilación del propio paquete o aplicación. Probemos esto de inmediato. Si, por ejemplo, eliminamos aquí las carpetas dist de auth y del sistema de diseño y luego ejecutamos la compilación de mi próxima aplicación, ahora también puedes usar los comandos Nx, que son más prácticos porque simplemente podemos ejecutar Nx build y luego elegir mi org my next app. Y puedes ver que ahora se ejecutan las compilaciones de dos proyectos dependientes, que son exactamente nuestras dependencias que tenemos. Y luego se ejecuta la compilación real de nuestra aplicación Next.js. Y la parte genial es que, si volvemos a ejecutar esto, está en caché. Por lo tanto, se dividiría inmediatamente y incluso podemos configurar esta configuración. Podemos seguir adelante y decir que no solo queremos ejecutar esto para el comando de compilación real, sino también si ejecutamos en modo de desarrollo para nuestra configuración.

Entonces, ahora que tenemos este espacio de trabajo, esta configuración de monorepo configurada, ¿cómo podemos aprovechar esta parte de migración? Bueno, agreguemos una aplicación remix. Lo único que voy a hacer es ingresar al directorio de aplicaciones y luego ejecutar el comando create remix app. Lo llamaré mi aplicación remix. Solo quiero tener lo básico, el servidor de aplicaciones remix. Quiero tener TypeScript y luego puedo agregarlo a mi espacio de trabajo. Si navego hasta la raíz de mi paquete y ejecuto npm nuevamente, se configurará y reconocerá mi aplicación remix, que está junto a mi aplicación Next.

Ahora que tenemos esta configuración, podemos enlazar los paquetes de la misma manera que lo hicimos en nuestra aplicación Next.js. Puedo tomar estos dos paquetes, ir a la aplicación remix y agregarlos también aquí en mi sistema, y ahora puedo importarlos desde las rutas de remix. Ahora tenemos nuestros botones importados aquí. Podemos seguir adelante y decir `bienvenido a remix`. Y eso está aquí. Coloquemos nuestro botón justo debajo. Instalemos las dependencias para que npm pueda vincular todo. Y ahora podemos ejecutar nuestra aplicación remix. Primero, nuevamente, precompilamos nuestros dos proyectos dependientes, como la autenticación y la biblioteca del sistema de diseño, pero ahora, si vamos a localhost:3000, tenemos nuestra aplicación remix en funcionamiento y también tenemos el botón incluido.

Lo que hemos visto aquí es una configuración muy flexible donde podemos configurar las herramientas como queramos. Pero para que también funcionen, debemos configurarlas. Esto es lo que llamamos una configuración de monorepo basada en paquetes, donde todos estos paquetes son potencialmente independientes, tienen sus propias dependencias, puedes elegir las herramientas de compilación que deseas tener y debes configurarlo todo para que funcione como se pretende. Ahora permíteme mostrarte una configuración diferente, que llamamos espacio de trabajo de monorepo integrado, que Ennex es capaz de configurar para ti. Y la diferencia es que viene preconfigurado, también es más opinativo, pero tiene un conjunto de complementos que te ayudan en el desarrollo de tu proyecto. Entonces, en este caso, nuevamente tenemos nuestra aplicación Next.js, pero por ejemplo, también para nuestros paquetes o bibliotecas, podemos generarlos, podemos configurarlos previamente y no tenemos que preocuparnos por cómo se realiza la configuración. Al tener instalada esta extensión de consola Ennex, incluso puedo hacer clic derecho y seleccionar aquí una biblioteca de React, que es mi sistema de diseño que quiero configurar. Y que se genere para mí, y esto configuraría el sistema de diseño de una manera determinada con una carpeta lib, algunas facilidades aquí que luego puedo consumir desde mi aplicación. De manera similar, puedo configurar mi biblioteca de autenticación, pero en este caso, puedo decir que es solo una biblioteca de JavaScript normal. No hay React en ella. Así que elijo el complemento de JavaScript novedoso y defino mi paquete de autenticación y lo genero también. Todo esto se configura automáticamente y se vincula con nuestra configuración global de TS base en el nivel raíz.

La experiencia aquí es muy agradable porque lo que podemos hacer aquí, por ejemplo, si devuelvo el nombre, puedo ir aquí y hacer referencia a eso. Y cuando ejecuto mi aplicación, se actualizará automáticamente cada vez que cambie algo en esa carpeta Auth. Así que puedo seguir adelante y servir aquí mi aplicación Next. Y si navego a 4200, verás aquí mi aplicación Next en funcionamiento. Veo aquí a John Doe. Y si vuelvo a mi aplicación Auth en mi biblioteca Auth y agrego un par de signos de exclamación, vuelvo atrás y verás que se actualiza automáticamente. Esto ya está configurado para ti. No tienes que configurar ningún paso predefinido ni scripts de observación, sino que esto funciona de inmediato.

Entonces, ¿qué pasa si quiero agregar ahora una aplicación de remix a esto? Bueno, puedo simplemente instalar el paquete de remix, el complemento de remix aquí. Y una vez que tenga el complemento instalado, puedo generar una nueva aplicación de remix, así que puedo ejecutar NX generar aplicación. Ahora debería ver la aplicación de Remix. Le doy el nombre, puedo darle un par de opciones si están disponibles, y luego genero la aplicación de remix dentro de mi carpeta de aplicaciones como hicimos antes.

Y ahora que tengo mi aplicación de remix configurada aquí, puedo simplemente hacer referencia e importar las cosas de la misma manera que en mi aplicación de Next.js. Así que vuelvo a mi aplicación de remix dentro de la carpeta de rutas. Importo el paquete de autenticación y lo uso de la misma manera. Vamos a ejecutar la aplicación de remix. Entonces, si cargamos la aplicación de remix, podemos ver que se carga, muestra a John Doe y también funciona con actualización en vivo. Así que si vuelvo a mi parte de autenticación aquí, elimino los signos de exclamación de nuevo, vuelvo atrás, puedes ver que ya se actualizó y visualizó el resultado para mí. Y esto es solo la punta del iceberg aquí. La principal ventaja de esta configuración integrada es que preconfigura el stack para ti. Así que puedes centrarte en la estructura de tu espacio de trabajo, pero no tienes que preocuparte por cómo construirlos, dónde preconstruirlos y, además, viene con facilidades como esos generadores, que hemos visto, que pueden hacer aún más, como generar acciones de remix, cargadores, metadatos para tus rutas y mucho más.

Entonces, ¿qué es más, esto realmente es un enfoque diferente para organizar y estructurar tu código en un espacio de trabajo de monorepo. Porque lo que sucede aquí es que tus aplicaciones en la parte superior se vuelven muy, muy delgadas y realmente solo son la parte de empaquetado de tu configuración específica de etiqueta. Aquí es donde incluyes los componentes en tu enrutamiento, cómo esa etiqueta específica como la configuración de Next.js o Remix lo demanda, mientras que los paquetes allá abajo están más encapsulados, están bien definidos, generalmente tienen límites de API bien definidos e incluso pueden ser independientes de la etiqueta.

Entonces, no tienen que serlo, porque algunos de ellos pueden ser cosas específicas de una función donde incluso exponemos cargadores de Remix, que se incluyen en una aplicación de Remix. Pero cosas como los flujos de trabajo de autenticación pueden ser totalmente independientes de la etiqueta y estar escritos en puro TypeScript. Y como puedes imaginar, esto permite una portabilidad mucho más fácil de las características. Y aunque tengas que refactorizar cosas, es mucho más fácil si ya se han extraído.

Lo que también obtienes de manera más interesante es que puedes ejecutar, por ejemplo, la visualización de un gráfico. Esto es específico de Nx, donde puedes ejecutar un gráfico de Nx y te mostrará la estructura de tu aplicación. Ahora, en nuestra configuración súper simple, solo tenemos dos aplicaciones que dependen de ambos paquetes. Pero en una configuración más avanzada, esto puede volverse más complicado. Y lo más importante, este tipo de configuración también se escala con tu equipo. Ahora es muy fácil asignar equipos a esos paquetes específicos donde uno trabaja en la parte de autenticación, hay otro grupo de personas y desarrolladores que trabajan en la parte del sistema de diseño, que se comparte más en diferentes aplicaciones que puedas tener. Pero luego también hay características como una lista de productos, donde otro equipo trabaja que se centra en el aspecto comercial de la aplicación. Y ahora que tienes esos paquetes más detallados, incluso puedes ejecutar las pruebas en un modo aislado solo contra la lista de productos, solo la parte de autenticación. Por lo tanto, es aún más fácil averiguar qué está fallando si las pruebas fallan porque son fácilmente identificables. Y además, si ahora ejecutas esto incluso en CI, dado ese gráfico que ahora está presente, es imposible ejecutar solo las cosas que se han modificado. Por ejemplo, digamos que modificamos un solo nodo en ese gráfico, entonces solo esos serían los que se prueban, construyen y vinculan en tu sistema de CI. Al mismo tiempo, esto también es una forma de diversificar tu stack. Porque como hemos visto, comenzamos desde una aplicación de Next.js y tenemos la intención de agregar una aplicación de Remix y luego migrar piezas. E incluso puedes tener múltiples aplicaciones, múltiples stacks de tecnología diferentes al mismo tiempo, que se implementan en diferentes tipos de destinos de tu organización. Y todo esto gracias a esa estructura modular donde las aplicaciones están desacopladas de los paquetes modulares reales. Entonces, en particular, también hemos visto hoy cómo podemos implementar ese stack con Nx y cómo eso puede ayudar.

Ahora, hemos visto dos enfoques diferentes de cómo usar Nx en esta configuración. El primero es probablemente más ideal si ya tienes un stack existente. Entonces, digamos que ya tienes ese espacio de trabajo de npm en una configuración así. Pero ahora quieres agregar Remix a eso y quieres que Nx te ayude a gestionarlo y escalarlo a medida que crece. Si estás comenzando de nuevo, probablemente te inclines hacia el tipo de configuración más integrada, que ofrece muchos más beneficios, como toda esa actualización rápida. La observación ya funciona. Pero al mismo tiempo, te brinda esa configuración predefinida donde no tienes que preocuparte por todos los detalles de nivel inferior por tu cuenta. La parte interesante aquí es realmente que Nx te ayuda no solo a escalar a medida que creces con características como el almacenamiento en caché local y remoto, sino que también viene con algunos aspectos agradables de DX, como una extensión dedicada de Visual Studio Code que puede ayudarte a desarrollar a largo plazo. Entonces, si esto suena interesante, definitivamente únete y síguenos en Nx Dev Tools, en Nx.dev, que es el sitio web principal, o también únete a nuestro Slack de la community, que puedes encontrar en la diapositiva aquí. Gracias por ver.