Microscopios: Cómo construir una aplicación moderna modular en un mundo de paquetes

Hola a todos, bienvenidos a mi charla, microscopios, sobre la agrupación de código en el mundo moderno de JavaScript. Pero antes de comenzar la charla, un poco, una pequeña historia. Así que esta increíble imagen que ven ahora mismo, el Pilar de la Creación, fue tomada por un telescopio espacial. Y este telescopio espacial se llama Hubble. Y Hubble fue lanzado en 1990, costando 4.7 mil millones de dólares para lanzarlo. Y fue un proyecto enorme, tal vez uno de los más grandes que la humanidad haya emprendido. Y fue lanzado, y fue asombroso, y no funcionó, porque algo estaba roto. La cámara estaba rota. Así que no pudieron arreglarlo. No pudieron traerlo de vuelta a la Tierra y arreglarlo. Así que tuvieron que entrenar a los astronautas durante tres años para ir allí arriba y arreglar la cámara. Y hoy en día, tenemos una solución mucho más simple. Así que hoy en día, estamos utilizando nano satélites, nano satélites, cientos de miles de satélites que están orbitando la Tierra. Y son realmente pequeños. Son realmente baratos. Es muy fácil lanzar cada uno de ellos. Y si uno de ellos se rompe, simplemente lo reemplazamos. Simplemente lo desactivamos y lo reemplazamos. Y eso es la autenticidad de una arquitectura modular. En lugar de enviar una cosa grande, un monolito si quieres, envías muchas cosas pequeñas. Y si algo se rompe, simplemente lo arreglas.

Soy Riyad Youssef. Soy el arquitecto de cliente en Dooda. Hoy hablaremos un poco sobre el mundo agrupado por encima y más allá. Entonces, ¿cómo gestionamos, cómo manejamos el código JavaScript agrupado? La primera pregunta que probablemente te hagas es ¿por qué? ¿Por qué necesitamos agrupar en absoluto? Tengo mi código, lo tengo en los archivos, ¿por qué necesito agruparlo? Para responder a eso, tenemos que retroceder un poco en la historia, un poco hacia la era de los dinosaurios, donde nuestras bases de código no se mantenían. Nuestros archivos se veían así. Teníamos archivos enormes, muchas líneas. Y si queríamos dividirlos en archivos más pequeños, teníamos que poner muchas etiquetas de script dentro de un documento, y era realmente difícil de mantener. Era realmente difícil de entender qué estaba sucediendo allí.

Entonces, hoy en día, queremos escribir algún tipo de código modular. Tenemos módulos en el navegador, pero aún no está completamente listo, así que simplemente escribimos módulos en nuestro código fuente, ¿verdad? Tenemos un código, un archivo, digamos app.jsx, y tiene dependencias. Tiene la dependencia app-reference, top, bottom y button. Tal vez tengan interdependencias entre sí, y tal vez esas dependencias tengan sus propias dependencias y se conecten entre sí. ¿Cómo manejamos eso? Tenemos Webpack. Webpack es hoy en día la forma estándar, y con un asterisco, porque hay muchas herramientas similares que lo mejoran un poco, pero Webpack es el estándar de facto para agrupar módulos. Así que hoy hablaremos un poco sobre Webpack y cómo usarlo. Así que solo un poco, una introducción a Webpack. Webpack crea un solo archivo, un solo paquete, que contiene todo el código, y lo hace, si no le decimos lo contrario, simplemente le decimos, está bien, le señalamos la entrada principal, el índice, el archivo principal, y le decimos dónde generar la salida.

Webpack funciona de esta manera. Va a la entrada, intenta entender a partir de la entrada cuáles son las dependencias, y las analiza, y de forma recursiva construye todo el árbol de dependencias y tal vez Lodash tenga su propia dependencia, y luego simplemente recopila todas las dependencias, entiende las dependencias y las agrupa. Las agrupa en un paquete ordenado Bundle.js. Básicamente serializa la dependencia con un poco de magia desde arriba, por lo que las serializa en un solo archivo, Bundle.js, y luego podemos tomar este archivo Bundle.js y usarlo en nuestro HTML. Podemos ponerlo en una etiqueta de script, porque eso es algo que los navegadores saben cómo manejar. Pero tenemos un problema, porque Webpack, a menos que se indique lo contrario, agrupará todo en un solo archivo. Aquí puedes ver un gráfico de dependencias. Es un gráfico de dependencias real de una aplicación de tamaño mediano, y si agrupas todo esto juntos, obtienes 15 megabytes de Bundle. Eso es suficiente para desesperar a cualquiera. Pero en Webpack, podemos hacer divisiones de código. Así que podemos definir para Webpack. Tenemos puntos de división en el código, por lo que no queremos agrupar todo en un solo archivo, sino que queremos, desde estos puntos, agrupar en este archivo y luego tener un fragmento dinámico. Así que divide mi código e inclúyelo solo cuando lo necesite. Esta es la forma más fácil de hacerlo.

Simplemente defines, si tienes una importación sincrónica o requerida sincrónica, sería el mismo fragmento. Pero si tienes lo que llamas una importación asíncrona o importación dinámica, será un fragmento diferente. Y este es un ejemplo del mundo real. Si quieres dividir en diferentes partes, en diferentes vistas, así es como lo haces. Así es como se ve internamente si haces una división de código en Webpack.

Entonces, cada color aquí representa un fragmento, un fragmento o un paquete, o una parte de un paquete. Y puedes ver todos los modelos que se incluyeron en este fragmento. Dicho esto, podemos usar eso en React, porque tenemos lazy en React, y podemos usar esos fragmentos dinámicos. Por ejemplo, si quieres traer el componente de matemáticas, solo si Elon Musk es verdadero, podemos usarlo con lazy, y si lo envolvemos en un suspense, incluso obtenemos un bonito spinner mientras el código intenta traer las matemáticas. Y si también ponemos earth dentro del suspense, tendremos un spinner para todo. Lazy es una buena manera, pero ¿cómo admitimos más de una pantalla con esta arquitectura? Es fácil.

Imaginemos que tenemos tres pantallas para la aplicación. Tenemos el panel de control, tenemos el editor, tenemos el sitio web. Simplemente los importamos de forma asíncrona y utilizamos React lazy, y en nuestra aplicación hacemos un switch o un if, lo que prefieras. Y luego le decimos a Waypack, oye, no agrupes todo en un solo archivo, sino crea fragmentos dinámicos. Es bonito. Eso es lo que Waypack sabe hacer. Toma todas las dependencias y envuelve incluso las dependencias comunes en diferentes fragmentos.

Los beneficios de esto son que tienes un único punto de entrada. No tienes que lidiar con la orquestación. No tienes duplicación de código, porque Waypack es inteligente, así que no duplica el código, pero tienes poca influencia en la división en fragmentos o en el orden de la división en fragmentos. No puedes construir parcialmente. Si quieres construir solo el panel de control, no puedes hacerlo. Tienes que ejecutar la compilación completa para todo porque tienes un único punto de entrada y es el mismo repositorio, el mismo lenguaje.

Así que hablemos de los múltiples puntos de entrada. Este es el ejemplo de un único punto de entrada. Pero ¿qué pasa si hacemos algo como esto? En la figura, decimos, okay, no agrupemos 100 puntos, sino 3: editor, panel de control y sitio web. Y luego creará 3 salidas, editor.js, sitio web.js y panel de control.js. Todavía comparten los fragmentos. Estos puntos de entrada, panel de control, editor y sitio web, y sus entradas, eventualmente recrean esos paquetes, esas salidas. Pero ahora necesitamos orquestar, porque ahora tenemos 3 archivos de salida diferentes. Nos corresponde a nosotros colocarlos en el HTML correspondiente. Así que necesitamos colocarlos en el HTML. Pero ¿por qué detenernos ahí? Podemos hacer múltiples WebEx en lugar de hacer múltiples puntos de entrada. Básicamente, múltiples WebEx significa que compartimos la compilación, pero construimos cada vez diferentes puntos de entrada. Tenemos 3 comandos de compilación. No es el mismo archivo de WebEx. Es un archivo de WebEx diferente. Cada archivo de WebEx tiene su propia entrada. Ahora podemos controlar qué va en cada archivo, en cada disco.

Ahora podemos controlar qué va en cada archivo, en cada disco. Podemos controlar las dependencias. Incluso podemos, lo que se llama, construirlo dinámicamente. Por ejemplo, en este ejemplo, estoy ejecutando el comando npm run build website. Solo construiremos website.js y luego npm run build dashboard. Solo construiremos dashboard.js.

Como puedes ver, las dependencias aquí se duplican. Y es fácil de ver. Porque WebEx no lo sabe. Cuando lo ejecutas así, WebEx no sabe que las dependencias de React se comparten. Porque lo ejecutas por separado. Así que obtienes un aislamiento completo. Por lo tanto, dashboard y command construirán dashboard.js. Y eso está completamente aislado. Puedes usar dashboard.js sin preocuparte por el sitio web. Y tienes control total sobre la compilación. Porque puedes ejecutar. Si algo cambia en el dashboard, puedes construir solo el dashboard. Eso está bien. Es el mismo repositorio y paquete. Desde la perspectiva de la developer experience, es muy fácil de mantener. Y puedes hacer implementaciones incrementales. Nuevamente, construyendo solo lo que cambia. La desventaja es que duplicas el código. Porque duplicas la dependencia. Y necesitas orquestación. Nuevamente, porque eventualmente, no tienes un punto de entrada. Tienes múltiples salidas. Entonces necesitas decidir qué salida va a dónde. Entonces, una idea para la orquestación, y creo que es buena, es generar todo como UMD.

UMD es una definición de modelo universal. Esto significa que puedes consumirlo de forma dinámica. Puedes consumirlo de forma asíncrona. Y luego tener un pequeño archivo de gestor de modelos. Y su único propósito es obtener el nombre del modelo. Y luego hacer un require, como un require de AMD, y devuelve una promesa con este modelo.

Y ahora es súper fácil. Porque ahora, si soy un archivo que quiere usar el editor, no me importa dónde se encuentre el editor. Solo voy al gestor de modelos. Y digo, necesito obtener el editor. Y luego el gestor de modelos devolverá la API del editor, o lo que el editor exponga. Y puedo hacer con él lo que quiera. Y el panel de control lo mismo. Solo voy al gestor de modelos. Y el gestor de modelos tiene todo este conocimiento. E incluso puedes, en esta arquitectura, incluso ponerlo en S3. Puedes ponerlo en la nube. No importa, siempre y cuando el gestor de modelos sepa qué definirá esos archivos, es suficiente. Y eso es realmente bueno. Es una idea realmente buena. Pero duplica el código.

Y veamos un ejemplo aquí. Por ejemplo, tenemos todos estos personajes. Y sabemos que los Vengadores son el Capitán América, Iron Man, Thor, Wanda y Vision. Pero sabemos que los Guardianes de la Galaxia también necesitan a Thor, ¿verdad?, porque está en la película. Y WandaVision necesita a Wanda y Vision. Entonces, la cuestión es, si tenemos este gráfico de dependencias y lo construimos con estas tácticas de múltiples WebPacks, tendremos código duplicado. Porque el paquete de los Vengadores tendrá a Thor, Wanda y Vision. Pero también, los Guardianes de la Galaxia tendrán a Thor, y WandaVision tendrá a Wanda y Vision. Y luego, si intentamos juntarlos a todos, simplemente es código duplicado.

Entonces, una herramienta útil para evitar la duplicación es usar externals de Webpack. Los externals básicamente le dicen a Webpack: tengo esta dependencia, pero no la empaquetes tú mismo. Así que no intentes empaquetarla. Pero yo la proporcionaré. Por ejemplo, aquí especificamos los externals react, react-dom y Thor en este ejemplo. Esto significa que cuando Webpack encuentra el require de react o de Thor, no intentará incluirlos en el paquete. Pero dependerá de mí proporcionarlos.

En este caso, Thor es único. Solo hay una instancia de él. Y yo debo proporcionarlo. Pero nuevamente, depende de mí orquestarlo. Necesito colocar el script externo antes de reutilizar mi aplicación. Y necesito aplicar la separación de código. Necesito aplicar la separación de dependencias. Así es como lo hacemos.

Tenemos un plugin de ESLint. Cuando intentas consumir código de un modelo diferente, por ejemplo, si estás en el panel y tratas de consumir algo del editor, tenemos una advertencia y la construcción falla porque has intentado importar un modelo externo. Podemos ver esto en, por ejemplo, el doEditor. Este es el editor. Este es el panel. Y este es el modelo que llamamos image speaker. Es el image speaker. Y la razón por la que es un modelo diferente, un modelo separado, es porque debe ser consumido desde el panel y desde el editor. Se construye de forma independiente.

Este es el editor. Es fácil de consumir. Simplemente decimos: `OK, abrimos una ventana emergente vacía. Luego solicitamos la API del image speaker o el image speaker, lo que sea que exponga. Y luego lo renderizamos en el contenedor de la ventana emergente. Y eso es todo.

Y nuestra aplicación completa consiste en diferentes modelos, múltiples WebEx. Así que es una muy buena manera. Es un enfoque realmente bueno si tienes una aplicación de tamaño mediano y aún quieres mantener tu código en el mismo repositorio. Pero quieres separarlo. Quieres construirlo por separado. Quieres implementarlo por separado. Así que tienes que tener este tipo de mecanismos para evitar importaciones cruzadas de modelos, como vimos, como el complemento ASLint. Pero una vez que lo tienes en su lugar y tienes el mecanismo externo en su lugar, es realmente fácil de mantener. Porque el equipo que está trabajando en el panel de control solo está trabajando en la parte del panel de control. Y puede consumir lo común si lo desea. Pero no interfiere. Y puedes ver aquí lo fácil que es consumirlo.

Si te suena familiar, es porque no está muy lejos de algo que llamamos micro-frontends. Y los micro-frontends van un poco más allá de lo que acabo de describir. En mi ejemplo de múltiples WebEx, tenemos un repositorio donde se encuentra todo el código. Y simplemente construimos diferentes partes por separado.

Los micro-frontends nos permiten ensamblar la aplicación a partir de partes independientes. Por ejemplo, si hablamos de la ISS (Estación Espacial Internacional), es algo enorme para nosotros tener en el espacio. No lo enviamos directamente, lo ensamblamos a partir de partes independientes, cada país lo construyó de forma independiente, lo lanzó de forma independiente, etc. Los micro-frontends nos permitirán incluso utilizar diferentes lenguajes o diferentes frameworks en nuestra aplicación. Cada equipo puede escribir en JavaScript, Go o lo que desee, porque a los micro-frontends no les importa el código en sí. Por ejemplo, este tipo de sitio web, esta aplicación web, podemos simplemente dividirla en diferentes partes. Y podemos tener diferentes equipos, incluso en lugares diferentes, construyendo esas partes. Y pueden estar en diferentes repositorios, incluso en diferentes tecnologías, diferentes frameworks. Y no nos importa, todo lo que necesitamos es la API para llamar al micro-frontend.

Pero aquí es donde se complica. Así es como se ve cuando los ensamblamos. Tienes diferentes repositorios, por lo que obviamente puedes hacer compilaciones y despliegues separados porque no se conocen entre sí. Tienes plena autonomía para cada repositorio, para cada equipo, pueden decidir cómo quieren hacer este proceso. La orquestación es muy importante. Y debes hacer algún tipo de gestión de dependencias. ¿Por qué? Porque son repositorios diferentes. No puedes compartir código común, como dijimos en las múltiples entradas de Webpack. Así que debes tener código común, ya sea como un paquete separado, como tu biblioteca de componentes, o como un externo si es una biblioteca que deseas consumir como externo. Debes tener orquestación porque necesitas conocer la versión, necesitas conocer la versión de cada micro-frontend. Debes tener descubribilidad porque cada micro-frontend necesita saber dónde están los demás, y composición. Hay frameworks para hacer eso, o hay bibliotecas para hacer eso. Solo para mencionar algunos, puedes escribirlo tú mismo o usar single SPA, o usar la idea de iFrames. Así que cada micro-frontend se coloca en iFrames o tiene inclusiones del lado del servidor, las opciones son ilimitadas.

Entonces dirías, bueno, tenemos el problema resuelto, pero no es tan fácil, ¿verdad? Porque ¿quién quiere mantener cientos de paquetes o incluso docenas de paquetes, cada uno en diferentes personas, pequeños paquetes que necesitas descargar el código y luego escribirlo y luego hacer un PR y luego esperar a que se publique? Realmente no quieres hacer eso, nadie quiere hacer eso. Así que tenemos un solo repositorio para el rescate porque muchas de las verdades en las que nos aferramos dependen de nuestro punto de vista, y podemos simplemente ponerlo de nuevo en el mismo repositorio.

Entonces tenemos diferentes paquetes, pero el mismo repositorio. Nuevamente, tenemos el problema de la versión. ¿Cómo sabemos cuál es la versión de cada uno? Pero nuevamente, tenemos herramientas como Learner. Es una herramienta muy poderosa que te permite construirlos todos juntos, gestionar la versión juntos, implementar, probar todo junto. Recomiendo encarecidamente que lo revises si tu aplicación es una que necesita usar Monorepo, facilita mucho el trabajo con Monorepos. También está buildvilt, eso también es interesante. Ahora hablemos de la separación versus la duplicación. ¿Verdad, necesitamos decidir, es como un compromiso? Necesitamos decidir, ¿queremos separar el código o podemos arriesgarnos a duplicar el código? Porque hagamos un pequeño resumen de lo que vimos hasta ahora. Puedes decirle a webpack, está bien, empaqueta todo y encárgate de las dependencias tú mismo y encárgate de la fragmentación tú mismo. Y eso es increíble y eso es realmente bueno. Eso es lo que obtienes cuando ejecutas, por ejemplo, Create React App, eso es lo que obtienes de inmediato porque tienes un único punto de entrada, no necesitas preocuparte por eso. Pero luego, cuando comienzas a construir una aplicación más grande, cuando comienzas a decir, está bien, tal vez tengo diferentes equipos o tengo diferentes personas trabajando en diferentes áreas, quieres tener la capacidad de decidir qué quieres construir o qué quieres implementar si tienes diferentes partes de las aplicaciones. Y en un único punto de entrada, no puedes hacer eso. Entonces puedes tener múltiples puntos de entrada como vimos, puedes decirle a Webpack, eh, construye esos puntos de entrada o simplemente construye el punto de entrada que quiero. Y luego tienes un poco más de libertad, pero luego tienes el dolor de cabeza de orquestarlo, de decir, construí mi panel de control, construí el editor, construí el selector de imágenes, pero ahora necesito escribir el código que sabe dónde está todo y luego consumirlo. Y también pierdes toda la gestión de dependencias o la gestión de dependencias comunes que Webpack proporciona. Entonces, una solución es la federación de modelos, que es realmente genial. La federación de modelos es algo nuevo que Webpack lanza. Digamos que la aplicación uno es una aplicación anfitriona y quiere consumir algo de la aplicación dos, pero no quiere duplicarlo. La aplicación uno es la cáscara, la aplicación dos es la naranja y quiere consumir el botón. Entonces, la aplicación uno simplemente lo define en su configuración, dice, eh, soy la aplicación uno, estoy usando una federación de modelos, es algo nuevo en Webpack y mi remoto es la aplicación dos. Entonces quiero consumir el botón de la aplicación dos, pero no quiero que se empaquete en mi código. De acuerdo, y estoy dispuesto a compartir React y React DOM con él. La aplicación dos es la remota, dice que soy la aplicación dos, estoy exponiendo el botón y también puedo compartir React y React DOM. Y luego, en la aplicación uno, simplemente lo importamos desde la aplicación dos, aplicación dos / botón. Y en la aplicación dos, simplemente lo importamos localmente. Y es realmente increíble porque en este tipo de mecanismo, podemos hacer algo aún más complejo. Podemos tener una aplicación principal que solo expone React y React DOM, las bibliotecas. Podemos tener una aplicación de componentes que solo expone componentes y podemos tener aplicaciones que usan esos componentes.

Y en lugar de agrupar todo junto, simplemente definimos los archivos de configuración adecuados de Webpack. Así que los definimos adecuadamente, por ejemplo, la aplicación principal está consumiendo libapp y la aplicación de componentes. Y luego simplemente los consumimos y tenemos esta dependencia solucionada. Es como magia.

Puedes leer más al respecto en todas partes de la web. Hay muchas otras técnicas, por ejemplo, el empaquetado web o los paquetes web. Es como una cosa inestable que te permite agrupar un sitio web en un solo archivo. Y lo importante es recordar que no necesitas elegir entre la separación de código y las dependencias duplicadas, puedes tener ambas y el futuro es realmente increíble. Así que solo mira hacia adelante y muchas gracias.

Soy Liad Yussef. Puedes encontrarme en Twitter si quieres. Muchas gracias. ♪♪