Aplicaciones Web Inmutables

¿Cómo les va, JS Nation? Hoy vamos a hablar sobre aplicaciones web inmutables y dependencias. Primero, soy Andy Damaris, pueden encontrarme en prácticamente todas las redes sociales como Teradox y mi sitio web es teradox.tech.

Lo que vamos a cubrir hoy es, vamos a comenzar con el problema. Hubo un problema que estábamos teniendo en Meltwater y luego pasaremos a las aplicaciones web inmutables, qué son y por qué las estamos usando, dependencias sin agruparlas, referenciando esas dependencias y finalmente hablaremos sobre cómo nosotros o esas dependencias con éxito.

Entonces, ¿cuál es el problema? Bueno, el problema eran las dependencias. Teníamos muchas y estaban siendo creadas por equipos internos para bibliotecas que podíamos usar regularmente para cosas como autenticación o búsquedas de empresas o búsquedas de usuarios y cada una de estas cosas estaba comenzando a acumular la cantidad de JavaScript duplicado que se estaba agrupando con todas las diferentes aplicaciones que estábamos enviando. Entonces, necesitábamos encontrar una forma de desagrupar estas dependencias y permitir que se compartieran de manera más efectiva entre las muchas aplicaciones que las estaban utilizando.

Entonces, las aplicaciones web inmutables fueron una parte importante de ese proceso, así que las vamos a cubrir primero. La filosofía básica de las aplicaciones web inmutables es que quieres construirlas una vez y desplegarlas muchas veces. Hay algunos fundamentos realmente específicos que necesitamos lograr para ser una aplicación web inmutable. El primero es que todas nuestras variables de entorno deben estar fuera del paquete. Esto permite que nuestros paquetes se construyan una vez por versión y sean inmutables para esa versión específica. Nunca cambiarán después de la primera vez que se construyan. También significa que necesitamos desplegarlos en una URL donde la versión que acabamos de construir esté incluida como parte de esa URL. Así que queremos que la URL completamente calificada tenga nuestro número de versión en algún lugar.

Ahora, ¿qué beneficios nos brinda esto realmente? Hay muchos. El primero es que cuando estamos probando en entorno de pruebas y estamos probando en producción, están utilizando los mismos activos exactos. La única diferencia será la configuración que ha cambiado entre los dos. Esto significa que todos nuestros activos también se pueden almacenar en caché al máximo. De hecho, se pueden almacenar en caché durante todo un año, que es el máximo actual del navegador. Esto es de gran beneficio para nuestros clientes. Solo necesitan hacer una solicitud para esa versión específica de ese activo específico una vez. Y después de eso, está en la caché de su disco local, lo que ahorra una gran cantidad de tiempo para las cargas secundarias y terciarias del sitio. Nunca tenemos que preocuparnos de que tengan que volver constantemente al origen por estos activos grandes en ocasiones. Otras cosas que se incluyen con esto son que siempre sabes qué versiones están desplegadas porque tu página de índice.html lo deja muy claro. Mira tu etiqueta de script. ¿Qué versión hay en la URL? Esa es la versión con la que estás tratando. También significa que los rollbacks ahora son realmente triviales. Solo estamos volviendo de una versión específica de un conjunto de activos a otra etiqueta de script. Otra versión específica de un conjunto de activos.

Y si ya eres un consumidor, es probable que ya tengas esa versión anterior de los activos en tu caché de disco listos para usar. Así que ni siquiera tendrás que pagar nuevamente los costos de descarga por ello.

Entonces, hemos hablado de todos nuestros activos, pero ¿qué pasa con la página de índice? Bueno, la página de índice es la única parte de una aplicación web inmutable que no se almacena en caché. Es nuestro punto focal donde todos nuestros cambios pueden aparecer de inmediato.

Así que nos gusta dividir las cosas en tres procesos de pensamiento diferentes. No es necesario hacerlo de esta manera, es solo un ejercicio para pensar en las cosas. La primera parte es nuestro alojamiento web estático. Aloja nuestra página HTML de índice. Esa página HTML de índice es bastante estática. No tiene mucha naturaleza dinámica. Y dicta las versiones de todos los activos estáticos que vamos a entregar. Luego, esos activos estáticos se entregan mediante etiquetas de script. Y esas etiquetas de script utilizan la URL completamente versionada de la que estábamos hablando. En este caso, la versión 1.2.3 para poder entregar esos activos.

Luego también tenemos nuestras APIs, y nuestras APIs pueden estar en un servidor diferente, pueden estar en el mismo servidor. Pero dictamos a qué API vamos a acceder mediante ese bloque de configuración que ves en la etiqueta de script. Ese bloque de configuración le dice a nuestra aplicación a dónde debemos ir para acceder a esa API y cuál debería ser la ruta, eliminando esa variable de entorno de nuestro código JavaScript.

Así que he pasado rápidamente por las aplicaciones web inmutables. Hay más matices, muchos más detalles en los que podrías profundizar. Y si eso es algo que te interesa, por favor visita immutablewebapps.org.

Así que ahora volvamos al meollo de lo que estamos hablando, que son las dependencias. Tenemos muchas de ellas. Son utilizadas por muchas aplicaciones diferentes. Entonces, ¿cómo solucionamos ese problema? Bueno, vamos a necesitar algunas herramientas para hacer esto con éxito. La primera herramienta que vamos a utilizar son los UMDs. Son un tipo específico de agrupamiento del estilo de Universal Module Definition.

Casi todos los agrupadores lo admiten y permiten que esos agrupadores den un nombre específico a un paquete de código que luego terminará en el ámbito global del disco en el navegador. El beneficio de esto es que ahora podemos hacer referencia a ese módulo utilizando el espacio de nombres global del disco que ocupa para traerlo sin tener que agrupar esa dependencia en nuestro otro código.

El ejemplo con el que vamos a trabajar hoy es Meltwater Visualizations. Y notarás que cuando hablamos de hacer un nombre para este paquete UMD, incluimos ese sufijo de una versión principal. En este caso, la versión principal 14 de Meltwater Visualizations. La razón de esto es que cuando hacemos referencia a una versión principal, nos permite cargar múltiples versiones principales de la misma dependencia en la página al mismo tiempo. Ahora, es posible que pienses que eso parece una mala idea, y estoy de acuerdo contigo. Pero también hay beneficios al poder hacer eso. Cuando tienes muchas dependencias entrelazadas, no todas podrán avanzar al mismo ritmo.

Actualizar una dependencia, como visualizations, a la versión 14 cuando otras personas dependen de la versión 13 podría significar que todos tengan que actualizar al mismo tiempo y hacer una actualización muy grande. Pero si puedes cargar Meltwater Visualizations 13 y Meltwater Visualizations 14 al mismo tiempo, les das a esos otros equipos la oportunidad de actualizar a su propio ritmo, a un ritmo razonable que tenga sentido para la carga de trabajo que tienen. Y eso significa que las versiones pueden avanzar más lentamente. Y en lugar de tener que hacer una actualización muy grande, ahora puedes actualizar las versiones cuando tenga sentido hacerlo para el movimiento de tu equipo.

Ahora, esto no significa que no debas tener cuidado con mucha duplicación de código, eso es cómo llegamos aquí en primer lugar. Pero sí significa que hace que esa ruta de actualización sea mucho más fluida en muchos equipos diferentes. Entonces, ¿cómo usamos los UMDs dentro de nuestro paquete? Hacer referencia a ellos se reduce a las herramientas de agrupamiento. Comenzaremos con Webpack. Webpack tiene una propiedad llamada externals. Los externals nos permiten cargar esos UMDs que se han colocado en el ámbito global del disco haciendo referencia a ellos mediante su nombre de módulo. Al usar su nombre de módulo, le decimos a Webpack que no queremos agrupar este módulo de nodo más. En su lugar, queremos hacer una referencia a ese módulo de nodo en este espacio de nombres global del disco correspondiente.

Entonces, aquí están sucediendo un par de cosas. Uno, se le dice a Webpack que ignore la agrupación de ese nombre de módulo, y dos, ese nombre de módulo se configura para que corresponda a un objeto de espacio de nombres global del disco que debería existir. El beneficio de hacerlo de esta manera es que cuando estamos testing con algo como Jest o VTest, aún podemos usar ese módulo de nodo para ejecutar nuestras pruebas. No es necesario que haga referencia al código específico del navegador si no queremos. Esto significa que nuestras pruebas y simulaciones son mucho más sencillas que si siempre dependiéramos del espacio de nombres global del disco. El beneficio aquí son configuraciones de prueba más fáciles, más fáciles de debug, y tu código local se ejecuta de la manera que esperarías. Es maravilloso saber que podemos usar el módulo de NPM para testing local y saber que actuará de la misma manera que cuando está implementado.

Ahora veamos cómo podría ser una configuración de rollup para esto. En rollup, esas dos cosas de las que hablamos que Webpack maneja en los externals se dividen en dos opciones de configuración separadas.

La primera es qué modules no se agruparán junto con nosotros. Para eso sirve la propiedad externa en rollup. Dice, aquí están los modules, simplemente no quiero que los cargues. No necesitas agruparlos en mi paquete. Y luego, en la opción global de salida, podemos usar el mismo tipo de mapeo que vimos en Webpack, donde el lado izquierdo es el nombre del módulo, y el lado derecho es el espacio de nombres global en el disco que queremos resolver para ese nombre de módulo mientras se está agrupando. Tiene una salida muy similar en la forma en que estamos haciendo referencia a estas cosas, y hace que sea muy sencillo hacer referencia a los UMDs desde el objeto window.

Pero si empezamos a pensar en cuando llegamos a 20 o 30 o 50 de estas dependencias, mantener esa configuración es agotador. Hay tanto que mantener. Cada una de ellas tiene una versión principal que tenemos que tener en cuenta. Cuando actualizamos nuestro package.json, esa versión principal podría cambiar y tenemos que recordar actualizarla en la configuración. Quiero decir, se vuelve un poco caótico, pero afortunadamente podemos automatizar eso y podemos hacerlo a través de un paquete llamado HiMyNameIs. Este paquete se va a abrir al público, esperemos que en el próximo mes y podrás aprovecharlo.

HiMyNameIs es básicamente una biblioteca que nos permite construir ese mapeo de módulos a espacios de nombres del que estábamos hablando sin que tengas que mantenerlo tú mismo. Y lo hace con dos funciones muy sencillas. La primera función se llama generateNamespaceFromPackage. generateNamespaceFromPackage te permite construir ese espacio de nombres global del que estábamos hablando, incluyendo nuestra versión principal para que podamos agregarlo a una nueva propiedad de package.json. Esa propiedad de package.json se llama browserNamespace. Esta propiedad nos da la capacidad de resolver esa información más adelante en la construcción. Así que una vez que tienes una biblioteca que está utilizando esto y construyendo esa propiedad en package.json, significa que tus consumidores ahora están configurados para poder referenciarlos correctamente. Veamos cómo se ve eso.

La segunda función de HiMyNameIs es getPackageNamespaceMapping. Esta función va a tu package.json de tu proyecto y mira todas las dependencias. Ignora las dependencias de desarrollo y resuelve esas dependencias para mirar sus package.json. Si el package.json de esa dependencia tiene una propiedad browserNamespace, lo utiliza para construir el mapeo del nombre del módulo al espacio de nombres global. Así que ya no tienes que mantener eso. A medida que vas versionando, se versionará automáticamente para ti. Cada vez que construyes, esto se resolverá de manera adecuada y rápida y te dará ese mapeo que necesitas. Así que en rollup, es un poco más complicado, pero no mucho. Al igual que con webpack, la función getPackageNamespaceMapping te sigue dando ese objeto globals, pero también necesitas construir ese array externo, como mencionamos anteriormente. Afortunadamente, getPackageNamespaceMapping tiene toda la información que necesitas para poder hacerlo con éxito.

De acuerdo, pero aún no hemos abordado el ordenamiento, ¿verdad? Y ese es un problema mucho más difícil, porque las dependencias pueden tener dependencias pueden tener dependencias, y todas deben cargarse en el orden correcto para que esta resolución global funcione correctamente. Pero también podemos automatizar eso. Ahí es donde entra en juego la herramienta de línea de comandos Orchard. De manera muy similar a HiMyNameIs, lee tu package.json, solo mira tus dependencias, ignora las dependencias de desarrollo. Pero en lugar de detenerse en el nivel superficial esta vez. Utiliza un paquete directamente de NPM JS llamado Arborist para construir el árbol completo de dependencias.

Arborist es básicamente el responsable de la resolución del árbol de dependencias para cosas como la instalación de NPM. Permite que la instalación de NPM construya ese árbol de dependencias completo para comprender qué nuevos paquetes deben colocarse en qué lugar en ese árbol de dependencias. También ayuda a construir el archivo package-lock.json. Es una herramienta muy poderosa que no construimos para que este sistema funcione.

Utilizando ese árbol de dependencias, luego construye un conjunto de etiquetas de script basadas en esa resolución del árbol de dependencias. Y luego limitamos eso utilizando un conjunto seleccionado de archivos YAML. ¿Por qué una lista seleccionada de dependencias? Bueno, hay un par de razones. La primera principalmente es la seguridad. No queremos que se cargue cualquier paquete de node o de NPM. Realmente queremos limitarlo a solo las cosas que realmente queremos que se carguen en el navegador. Al limitarlo, estamos limitando la cantidad de cosas que pueden cargarse a un subconjunto muy específico que realmente nos importa. También ayuda a limitar esa resolución del árbol de dependencias a un tiempo mucho más corto al recortar ramas que ya no son relevantes.

Entonces, con estas herramientas en su lugar, ahora tenemos este archivo YAML con el que debemos preocuparnos en el Orchard. Afortunadamente, es un archivo YAML bastante sencillo. Esto es lo que parece para una dependencia interna. En la parte superior, tenemos información de propiedad. Es maravilloso dentro de una gran organización poder saber exactamente quién es responsable de la dependencia en la que confías en producción. Eso es parte de lo que nos permite controlar el Orchard. Cada uno de estos archivos YAML tiene una propiedad `owned by`, un repositorio y una propiedad de contacto que nos permite realizar un seguimiento muy cercano de quién está realmente a cargo de estas diferentes dependencias. Luego, en los detalles técnicos, aquí es donde realmente estamos construyendo la ruta para cada una de las dependencias que estamos cargando, ya sea mediante una etiqueta de script o una etiqueta de enlace. Lo dividimos en estas tres partes por una razón muy específica. Queríamos un sufijo que sea la ruta base desde la que se cargarán estas cosas. Luego queríamos una ruta de versión que permita que esa ruta de versión se prefije con una `v` o un símbolo `@` dependiendo de dónde se esté cargando. Luego, el sufijo son los archivos específicos que deben cargarse. En el caso de lo que estamos viendo, esto cargaría una etiqueta de script con el tipo `module` y luego resolvería esa ruta base más la versión más la ruta ESM como origen de esa etiqueta de script. También crearía una etiqueta de enlace basada en eso, una vez más, esa ruta base, la versión y la ruta CSS para construir esa etiqueta de enlace que nos permite crear un conjunto de dependencias ordenadas. Hay otras dos propiedades aquí que vale la pena mencionar. Una es `conflicts with other major versions`, que es esa advertencia anterior de que intentamos asegurarnos de que nuestras bibliotecas internas puedan ejecutarse con múltiples versiones principales al mismo tiempo. Y este sería el lugar donde detendríamos una compilación si se intentaran cargar dos versiones diferentes de la misma biblioteca que no pueden interoperar correctamente.

Y el último aquí requiere inicialización. Hay algunas bibliotecas internas que requieren que se ejecute algún código de inicialización para que estén en un estado adecuado. Y nos gusta destacarlo para nuestros consumidores para que sepan exactamente lo que necesitan inicializar. Al mirar un ejemplo de una dependencia externa, se ve muy, muy similar a una dependencia interna. En este caso, moment.js. Podemos ver que las propiedades de propiedad han cambiado un poco. Ya no es una preocupación interna, por lo que no tenemos cosas como el nombre del equipo. Pero sí tenemos cosas como el repositorio del que proviene y dónde puedo contactarlos en caso de algún problema. Los detalles técnicos también son muy similares. En este caso, se utiliza ES5 en lugar de ESM porque no hay una versión ESM de moment.js. Así que todo eso significa que en lugar de ser una etiqueta de script con type=module, ahora obtendremos una etiqueta de script con el atributo defer, lo que básicamente permite que esa etiqueta de script se diferida hasta que se haya analizado todo el HTML y seguirá el mismo proceso de ordenamiento que una etiqueta de script con type=module cuando estamos haciendo esa resolución. Aquí podemos ver que tenemos conflictos con otras versiones principales establecido en true. No se pueden cargar múltiples versiones principales de moment. Simplemente no está permitido. Ocupan el mismo espacio de nombres this global y se sobrescribirían entre sí. Así que esos son un par de ejemplos de archivos YAML que se utilizan para configurar el orchard. Quiero tomar un segundo para hablar sobre algunos de los resultados de este trabajo, los beneficios que nos ha proporcionado en Meltwater. Y la gran cosa aquí es que es algo bueno. Realmente nos ha ayudado a reducir los problemas de los clientes que estábamos experimentando al tener el entorno de pruebas y producción que dependían de las mismas versiones exactas del código. Ya no nos preocupamos por los cambios de lógica que podrían colarse entre el entorno de pruebas y producción. También hemos reducido el tamaño general de nuestros paquetes para nuestras aplicaciones al hacer que esas dependencias sean externas. Esas dependencias pueden ser utilizadas por muchas aplicaciones diferentes en nuestra suite de aplicaciones ya que todas se cargan en el mismo dominio. También hemos visto que las cachés se están utilizando mucho más. Estamos viendo muchas menos solicitudes de archivos remotos ya que pueden almacenarse en caché en el navegador. Realmente ha ayudado mucho con los tiempos de carga para los usuarios. Así que un resumen rápido de todo lo que hemos hablado hoy es que teníamos un problema con muchas bibliotecas que se cargaban en muchas aplicaciones diferentes y esa duplicación de descarga de JavaScript. Así que adoptamos un enfoque de aplicaciones web inmutables para asegurarnos de que todos nuestros activos estuvieran completamente versionados y en caché al máximo. Los construimos utilizando UMDs, lo que permite crear ese espacio de nombres this global. Y también se pueden cargar a través de los empaquetadores que ya estamos utilizando. Y luego un poco de herramientas para DevAx es HiMyNameIs para permitir que esas dependencias se resuelvan más rápidamente y más fácilmente y también el orchard. El orchard es responsable de cargar esas cosas en un orden específico. Así que he cubierto mucho durante esta charla y sé que hay muchos temas aquí, así que gracias por su tiempo. Gracias por escuchar. Y si tienen alguna pregunta sobre alguno de estos temas, definitivamente contáctenme en las redes sociales. Haré todo lo posible para responder lo más rápido posible y responder cualquier pregunta que tengan. Muchas gracias de nuevo por su tiempo. Fue genial estar aquí para hablar.