Federación de módulos en Webpack 5

Rate this content
Bookmark

¿Microfrontends como monolito? ¿Biblioteca de componentes compartidos o guía de estilos? Esta técnica permite consumir módulos de compilaciones separadas, que pueden ser desarrolladas e implementadas de forma independiente. Una introducción y más ideas.

32 min
18 Jun, 2021

Video Summary and Transcription

Esta charla discute la federación de módulos en Webpack 5 como una solución escalable para dependencias compartidas en aplicaciones grandes. La federación de módulos permite compilaciones separadas para diferentes partes de una aplicación, reduciendo el tiempo de compilación y el retraso en la implementación. Incluye módulos expuestos y compartidos, carga asíncrona y creación de contenedores. La federación de módulos admite técnicas de orquestación de contenedores y tiene como objetivo integrarse con los módulos de ECMAScript. Sin embargo, la optimización y el intercambio en la federación de módulos pueden afectar el tamaño del código, y se requiere una evaluación cuidadosa. La actualización de los contenedores se puede gestionar mediante pruebas activas para garantizar la estabilidad.

Available in English

1. Introducción a la Federación de Módulos en Webpack 5

Short description:

Voy a hablar sobre la federación de módulos en Webpack cinco. La motivación es tener una aplicación de gran o mediana escala y trabajar con múltiples equipos en múltiples rutas de aplicación. Veamos las opciones existentes con Webpack. Hay una opción de hacer una compilación única y construir todas las aplicaciones y partes juntas.

Entonces, empecemos. He trabajado para el equipo principal de Webpack y voy a hablar sobre la federación de módulos en Webpack cinco. Mi charla trata sobre la federación de módulos en Webpack cinco. Quiero contarte sobre la motivación de esta característica, cómo funciona y cómo usarla.

La motivación es tener una aplicación de gran a mediana escala y trabajar con múltiples equipos en múltiples rutas de aplicación. Has separado tu aplicación o aplicaciones en múltiples partes, como micro front-ends, pero también partes lógicas. Estas partes serían desarrolladas de forma independiente por diferentes equipos. Otro requisito es que tienes varias partes compartiendo bibliotecas comunes o compartiendo en otras rutas. Aquí tienes un ejemplo. Podrías tener un componente de encabezado y un componente de sitio como micro front-end en las páginas. O también podrías tener una biblioteca de componentes de guía de estilo, que es compartida por todas las aplicaciones. Pero también cosas diferentes a los front-ends, como lógica de obtención de datos, lógica de negocio o componentes lógicos.

Veamos las opciones existentes con Webpack. Podrías simplemente usar los módulos nativos de ECMAScript. Esto significa que no tienes ningún proceso de compilación para vincular las partes entre sí. Podrías consumir nativamente todos tus módulos en las aplicaciones y usar las declaraciones de importación nativas del navegador para vincularlos. Pero hay algunos desafíos con este enfoque. Básicamente, renuncias a todas las optimizaciones que Webpack haría por ti, como eliminación de exploradores no utilizados, concatenación de módulos y otras optimizaciones. También hay algunos desafíos en cuanto al rendimiento web. Tendrías cada módulo por separado, lo que provoca un alto número de solicitudes al mismo tiempo. Cada solicitud tiene un costo adicional y obtienes una compresión menos efectiva con más solicitudes y archivos más pequeños. Por supuesto, los archivos más grandes suelen comprimirse mejor que los archivos más pequeños. Y tienes todas estas desventajas de solo poder usar módulos de ECMAScript y no poder usar módulos de CommonJS, módulos de CSS, ESM u otras cosas procesadas en Webpack.

Hay una opción de hacer una compilación única y construir todas tus aplicaciones y partes juntas. De esta manera, cada módulo de cada otra parte o aplicación es accesible durante el proceso de compilación. Puedes usarlos simplemente a través de declaraciones de importación. Pero también hay algunos cambios con ese enfoque. Cada actualización requiere una compilación completa de todas las aplicaciones y partes.

2. Desafíos y Federación de Módulos

Short description:

Entonces, tiene un tiempo de compilación alto y esto significa un alto retraso en la implementación desde la actualización hasta la implementación de la nueva versión de la aplicación. Pero hay un complemento en Webpack que te permite separar una parte de tu proceso de compilación en una compilación separada, que se puede construir de forma independiente. Una alternativa a esto son los externos y las bibliotecas integradas. En resumen, los módulos nativos de ECMAScript son problemáticos debido al rendimiento web problemático. Un proceso de compilación único es problemático en cuanto al rendimiento de compilación. Y el enfoque de DLL y externos funcionaría, pero requiere mucho trabajo manual para extraer bibliotecas compartidas, etc. Por lo tanto, al final, necesitamos una solución escalable, o al menos un compromiso que tenga un buen rendimiento de compilación, un buen rendimiento web, pero también una buena solución para las dependencias compartidas. Es por eso que entramos en la Federación de Módulos.

Entonces, tiene un tiempo de compilación alto y esto significa un alto retraso en la implementación de la nueva versión de la aplicación. Y también tienes este problema, que no puedes compilar cada aplicación por separado. Por lo tanto, tus aplicaciones no se mantienen separadas entre sí porque si quieres compartir partes comunes o bibliotecas comunes en algún momento tienes que compilarlas juntas. Es como un desafío al que tienes que enfrentarte.

Pero hay un complemento en Webpack que te permite separar una parte de tu proceso de compilación en una compilación separada, que se puede construir de forma independiente. En este escenario, construirías cada parte como una DLL con un llamado complemento DLL. Y estas DLL se pueden consumir al mismo tiempo por el consumidor que consume la compilación. Pero también tienes una dependencia de tiempo de compilación del manifiesto generado por la DLL. Así que eso también es un desafío y tienes que reconstruir tu aplicación cuando una parte ha cambiado o los consumidores tienen que ser reconstruidos. Es un retraso adicional en la implementación. No es tan alto en comparación con el enfoque de compilación única, pero sigue siendo un retraso adicional que no quieres tener. Y también hay un gran desafío en cuanto a compartir bibliotecas o módulos comunes. Básicamente, si varias partes comparten una biblioteca, tienes que extraer o extraer esta biblioteca compartida en una DLL separada y un proceso separado manualmente, y luego consumir la DLL generada por el proceso separado en todas las partes que comparten esta biblioteca. Hay mucho trabajo manual involucrado para poder compartir bibliotecas entre partes.

Una alternativa a esto son los externos y las bibliotecas integradas. Entonces, en este escenario, cada parte se construiría como una biblioteca y luego sería consumida por las partes consumidoras de las aplicaciones como externos. Esto elimina esta dependencia de tiempo de compilación entre partes y partes consumidoras, y otros módulos podrían ser simplemente consumidos desde la biblioteca en tiempo de ejecución. Pero aún así, el desafío de compartir bibliotecas sigue siendo cierto para este escenario. Cada biblioteca compartida debe ser extraída en un proceso separado, una biblioteca separada, y luego ser externa en cada una de estas partes consumidoras o aplicaciones consumidoras.

En resumen, los módulos nativos de ECMAScript son problemáticos debido al rendimiento web problemático. Un proceso de compilación único es problemático en cuanto al rendimiento de compilación. Y el enfoque de DLL y externos funcionaría, pero requiere mucho trabajo manual para extraer bibliotecas compartidas, etc. Por lo tanto, al final, necesitamos una solución escalable, o al menos un compromiso que tenga un buen rendimiento de compilación, un buen rendimiento web, pero también una buena solución para las dependencias compartidas. Es por eso que entramos en la Federación de Módulos. En la Federación de Módulos, construirías cada parte por separado. Y aquí construiríamos un llamado contenedor, y cada parte se publicaría o implementaría como contenedor. Y cualquier aplicación u otros contenedores podrían consumir módulos de este contenedor. En esta relación, el consumidor es el anfitrión y el contenedor sería el remoto. Y si el anfitrión consume módulos expuestos del contenedor, entonces se llamarían módulos remotos. Así que volvemos de nuevo a la separación, cada parte se construye por separado, de forma independiente y se implementa de forma independiente, por lo que tenemos este buen rendimiento de compilación.

3. Características de la Federación de Módulos y Módulos Compartidos

Short description:

Solo pagas por el tiempo de compilación de la parte que estás desarrollando. La Federación de Módulos viene con dos características: la exposición de módulos y los módulos compartidos. Los módulos expuestos se cargan de forma asíncrona, minimizando las solicitudes y cargando solo lo que estás utilizando. Los módulos compartidos pueden ser deduplicados dentro del ámbito compartido por versión. Se proporciona un ejemplo con una aplicación normal y dos equipos trabajando en componentes diferentes.

Solo pagas por el tiempo de compilación de la parte que estás desarrollando, o cuando la actualizas. Y todo el proceso se ve así.

La Federación de Módulos viene con dos características o aspectos. Y el primer aspecto es la exposición de módulos. Un contenedor puede exponer módulos y pueden ser consumidos por el host a través de módulos remotos. Un módulo expuesto se expondría de forma asíncrona, lo que significa que si solicitas un módulo del contenedor, este proceso sería asíncrono y el contenedor solo cargaría el código relacionado con tus módulos expuestos. Esto significa que solo tendrías que pagar el costo del contenedor y el costo de los módulos que realmente estás utilizando del contenedor. Por lo tanto, solo se descarga el código de los módulos que estás utilizando. Pero los contenedores aún pueden realizar optimizaciones, como agrupar las dependencias de los módulos expuestos juntos o extraer partes compartidas de los módulos expuestos de forma automática, o la optimización que pueden hacer para la carga automática es posible para los módulos expuestos. Esto vuelve a brindar un buen rendimiento web al minimizar las solicitudes y cargar solo lo que realmente estás utilizando.

El segundo aspecto es el aspecto de los módulos compartidos. En este aspecto, cada parte o cada participante del panorama de la aplicación puede proporcionar módulos, proporcionar módulos compartidos en el ámbito compartido. Estos módulos se proporcionan con información de versión adjunta. Por ejemplo, el contenedor podría exponer React en la versión 60.3 y eso se colocaría en el ámbito compartido. Y por otro lado, los contenedores o consumidores o cada participante del panorama pueden consumir módulos del ámbito compartido con una verificación de versión. Por lo tanto, se le podría solicitar al contenedor React en una versión 60.0 o superior y luego obtendría la versión más alta disponible en el ámbito compartido. De esta manera, los módulos compartidos pueden ser deduplicados dentro del ámbito compartido por versión y no tienes que descargar React dos veces si tienes un módulo compartido. Para los módulos compartidos, se aplica la misma carga asíncrona que con los módulos expuestos. Por lo tanto, solo pondrías cada módulo compartido en un archivo separado o lo descargarías por separado y solo tendrías que descargar los módulos compartidos que realmente estás utilizando. Por lo tanto, puedes proporcionar versiones antiguas de React, pero si solo estás utilizando la versión más nueva, no descargaría ninguna versión antigua.

Aquí tienes un ejemplo de cómo funciona esto. Comenzamos con una aplicación normal que tiene una página de inicio y en la página de inicio hay un enlace de inicio de sesión que abre el módulo de inicio de sesión y muestra un botón llamado `Iniciar sesión`. En la página de inicio hay un menú desplegable que muestra algo. Todo esto utiliza React en este escenario, pero el código del módulo de inicio de sesión se carga de forma asíncrona cuando se hace clic en el botón de inicio de sesión. Utilizando la carga bajo demanda para este escenario para mover esto a un fragmento separado o descargarlo por separado. En este escenario, tenemos dos equipos trabajando en esto. El equipo A está trabajando en la página de inicio y el módulo de inicio de sesión, por lo que son componentes. Y el equipo B está trabajando en la biblioteca de componentes donde tiene un componente de menú desplegable y también el componente de botón. Y así es como funciona con una compilación única. Todo está súper optimizado, pero apliquemos la federación de módulos a este concepto.

4. Federación de Módulos y Creación de Contenedores

Short description:

El equipo B marca sus propios componentes y dependencias como módulos expuestos en el gráfico. Webpack crea un contenedor con archivos separados para cada módulo expuesto y módulo compartido. Al solicitar un componente, se cargan en paralelo el fragmento correspondiente y sus módulos compartidos. El equipo A utiliza el contenedor como módulos remotos, con el desafío de cargar los módulos de forma asíncrona. El complemento de federación de módulos en Webpack 5 permite crear un contenedor exponiendo módulos mediante la propiedad 'exposes'.

Entonces, desde el punto de vista del equipo B, al equipo B solo le importan sus propios componentes, como los componentes de botón y el componente de menú desplegable, pero también sus dependencias, como un icono de flecha que se utiliza para el menú desplegable y también la biblioteca React. Y para usar la federación de módulos, el equipo B marcaría estos módulos en el gráfico, como el botón expuesto, el menú desplegable expuesto. Por lo tanto, 'expuesto' significa que están disponibles para su consumo desde la interfaz del contenedor. Y también marcaría React como biblioteca compartida. Por lo tanto, pueden compartirse con otros equipos en algún momento. Ahora Webpack crearía un contenedor para todo esto.

Entonces, en este contenedor, habría un módulo de entrada de contenedor generado por Webpack, que contiene referencias a todos los módulos expuestos, como el botón o el menú desplegable. Y Webpack también colocaría cada módulo expuesto en un archivo separado. Por ejemplo, aquí está el botón en un archivo separado, pero también el menú desplegable en un archivo separado, pero aún así sería capaz de agrupar las dependencias en la unidad del módulo expuesto. Por lo tanto, la optimización de fragmentación aún se aplica. También colocaría cada módulo compartido en un archivo separado, porque puede cargarse o no cargarse, dependiendo de si ya hay una versión vectorial disponible en algún momento. Por lo tanto, si tomamos algunos ejemplos, como si solicitas el componente de botón desde el contenedor, y el tiempo de ejecución cargaría el fragmento del botón. Por lo tanto, el archivo contendría el botón, pero también los módulos compartidos de este y requeridos por este fragmento, los cargaría en paralelo. Y en los escenarios en los que ya hay una versión de React, igual o superior disponible en algún momento, entonces la solicitud y el menú desplegable solo requerirían su propio fragmento de menú desplegable y el fragmento de React se cargaría desde otro lugar o no se cargaría en absoluto si ya se ha cargado antes.

Ahora, veamos cómo el equipo A utiliza este contenedor generado por el equipo B. Así es como se ve el gráfico de módulos para el equipo A. El equipo A solo se preocupa por sus propios componentes y cada componente del equipo B se editaría como módulos remotos. Por lo tanto, solo estoy diciendo que hay un contenedor y hay alguien en algún lugar y un menú desplegable que se consume desde el contenedor. Desde el punto de vista de Webpack, hay un módulo remoto, como el módulo de menú desplegable y cada módulo remoto apunta al contenedor como externo en algún momento. Pero aquí hay un desafío porque cargar módulos desde el contenedor de forma asíncrona requiere un poco de creatividad para resolver este problema porque si un módulo de inicio de sesión simplemente importa el componente de botón y la importación suele ser una operación síncrona. Por lo tanto, Webpack automáticamente elevaría cada operación asíncrona requerida para cargar estos módulos remotos hasta el siguiente límite asíncrono. Un límite asíncrono es como una declaración de importación asíncrona o algo así. Por lo tanto, en este caso, si haces clic en el enlace de inicio de sesión, que normalmente carga el código del módulo de inicio de sesión, cargará en paralelo el código del componente de botón desde el contenedor. Por lo tanto, haces clic en el enlace de inicio de sesión y el código del módulo de inicio de sesión y el código del componente de botón se cargarán en paralelo una vez desde la compilación local, una vez desde la compilación del contenedor. Sí. Y lo mismo ocurre con los módulos compartidos, pero no se explica en detalle aquí. Genial. Entonces, ¿cómo puedo usarlo? Para usarlo, hay un complemento de federación de módulos disponible en Webpack 5 y con diferentes propiedades tienes acceso a crear un contenedor, consumir otros contenedores, pero también compartir módulos en algún momento. Veamos cómo crear un contenedor. Para crear un contenedor, debes exponer módulos desde el contenedor, lo cual se hace utilizando la propiedad 'exposes'.

5. Características de la Federación de Módulos

Short description:

La propiedad 'exposes' asigna a cada módulo un nombre público y local. La clave 'remotes' se utiliza para consumir otros contenedores. Para compartir módulos, utiliza la propiedad 'shared'. Hay configuraciones avanzadas disponibles para compartir módulos y crear contenedores.

Entonces, la propiedad 'exposes' tiene algunas propiedades, como asignar a cada módulo un nombre público, como un sistema de seguimiento o datos, y un nombre local, que es donde se encuentra el módulo en el disco actualmente desde este fragmento, y para cada módulo admitido, puede ser un módulo ECMAScript normal, puede ser un módulo CommonJS, puede ser CSS, puede ser cualquier cosa procesada por cargadores, lo que sea.

Y para consumir otros contenedores, debes utilizar la clave 'remotes' o las propiedades remotas en el complemento de federación de módulos, y aquí le asignas a cada contenedor un nombre, como 'analytics', y todos apuntan a una ubicación del contenedor que se carga en un momento determinado, aquí se cargaría el script 'analytics.js' en un momento dado.

Para usar estos módulos remotos desde los contenedores, simplemente tendrías una declaración de importación con 'analytics', es decir, previamente con 'analytics', y luego el nombre público del módulo en el contenedor, el módulo expuesto en el contenedor, aquí, sistema de seguimiento. Sí.

Y para compartir módulos, tienes la propiedad 'shared'. Y en esta propiedad compartida, simplemente enumeras todos los módulos que deseas tener, que deseas compartir entre otros contenedores u otras aplicaciones. Como ejemplo aquí, 'react-virtualize-shared', pero también 'react-virtualize-the-styles' de 'react-virtualize'. Y también hay configuraciones avanzadas disponibles. Aquí, un ejemplo es que 'react' solo debe ser instanciado una vez en una página HTML. Por lo tanto, puedes utilizar una única configuración avanzada para asegurarte de que 'react' solo se cargue una vez. Para cada módulo compartido, Webpack determinará qué versión se proporciona buscando la información de versión en el 'package.json', pero también buscará la versión requerida para cada dependencia en tu lista de dependencias del 'package.json' o en una lista de dependencias de profundidad. Y sí, pero también puedes utilizar configuraciones más avanzadas para anular esto o pasar otras cosas o definir módulos de respaldo, definir claves diferentes, así como configuraciones avanzadas para la creación de contenedores y también para consumir contenedores disponibles. Si estás interesado, pausa el video y consulta los detalles.

6. Federación de Módulos y Orquestación de Contenedores

Short description:

A gran escala, tienes múltiples aplicaciones que utilizan bibliotecas de componentes, contenedores separados para las páginas y lógica de negocio compartida. Hay dos técnicas: evergreen, donde las aplicaciones siempre utilizan la última versión del contenedor, y managed, donde las aplicaciones registran la versión del contenedor y actualizan activamente. La Federación de Módulos permite que diferentes compilaciones actúen como un paisaje monolítico, admitiendo varios módulos de Webpack y habilitando la versión semántica. Solo carga los módulos que se utilizan, pero todas las exportaciones están disponibles. Los módulos federados son asíncronos y requieren límites de carga asíncrona. En el futuro podrían haber características más avanzadas.

A gran escala, esto podría verse así. Tienes múltiples aplicaciones que utilizan bibliotecas de componentes, utilizamos páginas como contenedores separados y también se comparte lógica de negocio o traducción. Así que hay todo este aspecto divertido sobre la orquestación.

Entonces, ahora hemos construido todos estos contenedores por separado, pero tienes que unirlos en un momento dado. Básicamente, hay dos técnicas que se me ocurrieron. La primera técnica es evergreen. Y esto significa que cada aplicación siempre utiliza la última versión publicada de un contenedor. En este escenario, si publicas un cambio en tus componentes del sistema de diseño, entonces cada aplicación obtendría instantáneamente la última versión de esto en tiempo de ejecución y no hay un paso adicional entre eso. Es como tener una estación de paquetes con un archivo de registro y ejecutar npm install cada vez que se carga la aplicación en el navegador. Es un poco arriesgado, pero podría funcionar a menor escala porque tu empresa tiene el control de todos tus contenedores. Así que si no haces un lío, esto podría funcionar para ti.

Pero también hay otro enfoque, lo llamé managed. Y en este escenario, la aplicación registraría la versión del contenedor que está utilizando. Es como tener un paquete que tiene un archivo de registro. Y al igual que con un archivo de registro, hay un paso activo para actualizar o actualizar la versión de tus contenedores que tu aplicación está utilizando. Así puedes validar si esta actualización de tus contenedores funciona para tu aplicación. Aquí es donde puedes probar a nivel de aplicación si los contenedores siguen siendo compatibles con tus aplicaciones. Y sí, podría haber múltiples etapas como entorno de preparación, producción, etc. Aquí hay algunas ideas de cómo resolver esto, pero no quiero entrar en detalles. Puedes pausar el video si estás interesado.

Entonces, para resumir, la Federación de Módulos te permite que diferentes compilaciones actúen como un paisaje monolítico, todo en un momento dado. Admite cualquier módulo compatible con Webpack, como ECMAScript, CommonJS, pero también CSS y muchos otros procesos. Compartir módulos está disponible para hacer versionado semántico en un momento dado. Está disponible para todos los tiempos de compilación, como Webnode, Web Worker, etc. Solo carga y descarga los módulos que realmente estás utilizando, pero siempre utiliza todas las exportaciones de ellos, así que debes tener en cuenta que hay un compromiso en cuanto a la optimización aquí. Y los módulos federados son asíncronos, por lo que necesitas tener límites de carga asíncrona en algún lugar del gráfico antes de poder utilizar los módulos federados. Así que si solo estás experimentando, tal vez haya cambios y rastros en el futuro, tal vez haya características más avanzadas en el futuro, sí, ya tengo algunas ideas que podrían venir, pero no quiero entrar en detalles ahora. Así que aquí tienes algunas fuentes que puedes consultar si estás interesado, como la documentación, otras charlas y más ejemplos disponibles en línea. Así que tengo que decir, gracias. Pero profundicemos en el tema de la federación.

QnA

Integración de los Módulos de ES y la Federación de Módulos

Short description:

Hay planes para hacer que los módulos de ECMAScript sean compatibles con Webpack, pero hay desafíos técnicos. El formato de módulo de ECMAScript como formato de salida para Webpack aún no está habilitado, pero se está trabajando en ello para Webpack 5. El objetivo es proporcionar compatibilidad con los módulos de ECMAScript, pero hay complejidades al combinarlos con CSS u otras características. Webpack busca equilibrar el progreso hacia adelante con la compatibilidad hacia atrás y la estabilidad. En cuanto a las pruebas de tamaño de paquete y tiempo de carga con la federación de módulos, no hay pruebas específicas, pero hay ejemplos disponibles para explorar y el objetivo es mantener la limitación de una sola ida y vuelta para la carga bajo demanda.

Tobias, ¿puedes unirte a mí en el escenario?

Claro.

Gracias por invitarme.

Sí, es bueno tenerte aquí.

Tengo que decir que eres un valiente al abordar estos problemas.

Así que no llevo un sombrero en este momento, pero me quito el sombrero ante ti y es genial que lo hayas hecho comprensible para una persona como yo que no está familiarizada con estos sistemas de compilación.

Vamos a profundizar en la pregunta de nuestra audiencia. La primera que tengo es de Albert G. ¿Hay alguna posibilidad de que Webpack permita integrar los módulos de ES como DLLs o convertir el sistema de módulos propietario de Webpack para que sea compatible con los módulos de ES?

Creo que con DLLs se refiere a los contenedores en términos de modificación también. Sí, hay planes para hacer que los módulos de ECMAScript sean compatibles con Webpack. Actualmente podemos utilizar los módulos de ECMAScript como externos. Entonces, si tienes un contenedor en formato ECMAScript, podrías lanzar este contenedor, pero no puedes producir un contenedor en formato ECMAScript. Básicamente, el formato de módulo de ECMAScript como formato de salida para Webpack aún no está habilitado. Aún no lo tenemos, pero estamos trabajando en ello para Webpack 5 y creo que estará disponible en la versión final. Sin embargo, hay algunos desafíos técnicos y no se trata de JS básico. Eso sería sencillo. Pero si lo combinas con CSS u otras cosas complejas, como si tienes lógica de interrupción en el bote como CommonJS y preguntas sobre el modo estricto, los módulos de ECMAScript siempre están en modo estricto, pero CommonJS generalmente solo puede optar por el modo estricto. Por lo tanto, habría algunos cambios de comportamiento en los módulos. Estas son las preguntas que estamos considerando. Es muy difícil hacer un futuro así que viene con otros constructores de manera sencilla, pero con Webpack tenemos muchas características que debemos admitir si queremos proporcionar algo así. No es tan fácil para nosotros agregar esto, pero estamos planeando agregarlo y probablemente agregaremos algunas limitaciones a eso, por lo que no podrás usarlo con estructuras complejas o tendremos algunas soluciones alternativas para que funcione. Pero si puedes relacionarlo con la discusión del panel que tuvimos antes, no quieres quedarte atrapado en el pasado, quieres seguir avanzando, pero sí, no puedes dejar a todos atrás. Eso, por supuesto, también te ralentiza a ti y a tu equipo. Creo que hay mucho valor en Webpack en cuanto a la estabilidad y la compatibilidad hacia atrás con el código existente. Tenemos una gran base de usuarios y no queremos dejarlos atrás con las versiones más nuevas. Queremos seguir admitiendo las características existentes, pero nuevamente, sí. Gracias, gracias por eso.

Vamos a pasar a la siguiente pregunta de Tudor. ¿Existen pruebas de tamaño de paquete o resultados de tiempo de carga al utilizar la federación de módulos? No tengo pruebas, pero SecJackson tiene un repositorio grande con muchos ejemplos y puedes probar muchos casos de muestra con la federación de módulos. Pero para resumirlo, queremos mantener, y básicamente, Webpack se basa en si cargas algo o no bajo demanda, solo debería tomar una ida y vuelta al servidor y descargar todo y tal vez hacer solicitudes paralelas para no cargar todo. Y queremos mantener esta limitación, mantener este objetivo para la federación de módulos, por lo que seguirá tomando una ida y vuelta al servidor.

Optimización y Compartición en la Federación de Módulos

Short description:

Con la federación de módulos, se puede perder la capacidad de optimización, lo que lleva a un aumento en el tamaño del código. Compartir módulos requiere proporcionar todas las exportaciones, lo que puede resultar en tamaños de módulo más grandes. Sin embargo, compartir módulos también puede disminuir el tamaño final al permitir compartir entre diferentes partes de la aplicación. El impacto depende del panorama de usuarios específico, por lo que es importante medir y evaluar los resultados.

Pero con la federación de módulos, se podría perder cierta capacidad de optimización. Por lo tanto, podría aumentar el tamaño del código si se comparten módulos con otros, debemos proporcionar todas las exportaciones del módulo. Por lo tanto, no sabemos qué exportaciones se utilizan en todo el panorama de la aplicación. Básicamente, preparamos nuestros módulos para que los use cualquier persona. Por lo tanto, podemos hacer menos optimización en este límite donde se unen los módulos compartidos o expuestos con otras aplicaciones de contenedores cargadas una vez, que no conocemos en tiempo de compilación. Por lo tanto, podría aumentar el tamaño final, pero también podría disminuirlo mediante el uso compartido, la capacidad de compartir módulos entre este tipo de partes microfinanciadas de la aplicación. Entonces, la respuesta corta es que depende. Depende. Sí, siempre es difícil, por supuesto, depende del panorama del usuario. Muy bien. Siempre hay que medir. Sí. Siempre es el usuario.

Aplicaciones Afectadas y Actualización de Contenedores

Short description:

Existen dos enfoques diferentes para determinar las aplicaciones afectadas en función de la actualización de un contenedor. El enfoque evergreen no proporciona información sobre los cambios en el contenedor, mientras que el enfoque gestionado implica probar activamente la aplicación con contenedores actualizados antes de implementarlos. Este enfoque garantiza la estabilidad al actualizar los contenedores.

La siguiente pregunta es de Amaya. ¿Hay alguna forma de determinar las aplicaciones afectadas en función de la actualización de un contenedor? Sí, en mi charla menciono dos enfoques diferentes. El enfoque evergreen no te permite saber cuándo cambia un contenedor. Pero el enfoque gestionado consiste en verificar que la aplicación siga funcionando con los contenedores actualizados. En este enfoque, probarías activamente tu aplicación con los contenedores actualizados, asegurándote de que todo funcione correctamente y luego implementar la nueva especificación de la aplicación con la última versión del contenedor. Este es el enfoque que debes seguir si te preocupa la estabilidad al actualizar los contenedores y así sucesivamente. De acuerdo. Tenemos un poco más de tiempo. Vamos a tomar otra pregunta. Esta pregunta es de Kirill. No estoy seguro de si entendí bien. ¿Cómo se comparten los contenedores entre los frontends? ¿Se implementan por separado? Sí, se implementan por separado. En cuanto a compartir estado, todos los módulos en todos los contenedores actuarán como aplicaciones monolíticas. Se comportarán como si fuera una sola página con todos los módulos. Por lo tanto, todos los módulos están básicamente en la misma caché. Cada módulo solo se instancia una vez y pueden compartir funciones que no están aisladas. Todos se agrupan en un ámbito de módulo común o algo similar a un módulo. Por lo tanto, puedes hacer todo lo que harías con el uso compartido de estado normal. Puedes colocar estado en tus módulos y utilizar un almacén de Redux como por ejemplo, y todas las aplicaciones, todos los contenedores podrían acceder al estado en este módulo expuesto o compartido. ¿Y cuál era la otra parte de la pregunta? ¿Cómo se comparten los contenedores entre los frontends? ¿Se implementan por separado? Sí, la forma más sencilla es implementar cada contenedor por separado, construir cada contenedor por separado e implementarlo en alguna ubicación o URL. Luego utilizarías esta URL para hacer referencia al contenedor desde las aplicaciones u otros contenedores. Por lo tanto, cada contenedor puede ser, y esa era la intención de todo este sistema, implementado por separado. Y en tiempo de ejecución, se vincularán y actuarán como una sola aplicación. De acuerdo, gracias. La última pregunta a la que tenemos tiempo es de Stefan. ¿Se pueden cambiar los paquetes, los módulos en tiempo de ejecución? Por ejemplo, si tengo 100 pruebas de AP y solo quiero enviar cinco a mis usuarios, ¿cuáles serían esos cinco? Solo lo sé cuando el usuario solicita mi aplicación. ¿Puede la federación de módulos ayudarme con esto? Sí, puedes hacer esto. Podrías compilar dos versiones de un contenedor y luego elegir en tiempo de ejecución qué contenedor quieres cargar. Básicamente, tendrías tu versión A y B y de forma aleatoria o con cookies o lo que sea, y en alguna condición puedes, si quieres enviarte un contenedor y en otro caso, enviar el otro contenedor y la aplicación lo usaría en tiempo de ejecución. Por lo tanto, todo se unirá en tiempo de ejecución en el navegador del usuario. Puedes cambiar todo. También es posible cargar dinámicamente los contenedores a través de una URL si deseas algo así. Como obtener una respuesta del servidor, como cargar este contenedor y luego el tiempo de ejecución podría cargar este contenedor y cargar algunas de esas instancias como algo que deseas cargar dinámicamente. De acuerdo, bueno, espero que todos hayan obtenido respuestas a sus preguntas pero para aquellos que no lo hicieron, por supuesto, Tobias estará en su propia sala de Zoom privada donde podrás preguntarle sobre la federación de módulos o Webpack en general, pero tratando de mantenerse en el tema. Así que Tobias, muchas gracias por esta increíble charla. Estoy deseando profundizar más en la federación de módulos. Gracias por tenerme. ♪♪

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
React Summit US 2023React Summit US 2023
96 min
Build a powerful DataGrid in few hours with Ag Grid
WorkshopFree
Does your React app need to efficiently display lots (and lots) of data in a grid? Do your users want to be able to search, sort, filter, and edit data? AG Grid is the best JavaScript grid in the world and is packed with features, highly performant, and extensible. In this workshop, you’ll learn how to get started with AG Grid, how we can enable sorting and filtering of data in the grid, cell rendering, and more. You will walk away from this free 3-hour workshop equipped with the knowledge for implementing AG Grid into your React application.
We all know that rolling our own grid solution is not easy, and let's be honest, is not something that we should be working on. We are focused on building a product and driving forward innovation. In this workshop, you'll see just how easy it is to get started with AG Grid.
Prerequisites: Basic React and JavaScript
Workshop level: Beginner
Node Congress 2023Node Congress 2023
49 min
JavaScript-based full-text search with Orama everywhere
Workshop
In this workshop, we will see how to adopt Orama, a powerful full-text search engine written entirely in JavaScript, to make search available wherever JavaScript runs. We will learn when, how, and why deploying it on a serverless function could be a great idea, and when it would be better to keep it directly on the browser. Forget APIs, complex configurations, etc: Orama will make it easy to integrate search on projects of any scale.
Node Congress 2022Node Congress 2022
128 min
Back to the basics
WorkshopFree
“You’ll never believe where objects come from in JavaScript.”
“These 10 languages are worse than JavaScript in asynchronous programming.”
Let’s explore some aspects of JavaScript that you might take for granted in the clickbaitest nodecongress.com workshop.
To attend this workshop you only need to be able to write and run NodeJS code on your computer. Both junior and senior developers are welcome.
Objects are from Mars, functions are from Venus
Let’s deep-dive into the ins and outs of objects and then zoom out to see modules from a different perspective. How many ways are there to create objects? Are they all that useful? When should you consider using them?
If you’re now thinking “who cares?“, then this workshop is probably for you.
Asynchronous JavaScript: the good? parts
Let’s have an honest conversation.
I mean… why, oh why, do we need to bear with all this BS? My guess is that it depends on perspective too. Let’s first assume a hard truth about it: it could be worse… then maybe we can start seeing the not-so-bad-even-great features of JavaScript regarding non-blocking programs.