Compartir es cuidar: Mejorando el rendimiento de Micro-frontends con el intercambio de dependencias

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Acompáñame mientras exploramos el lado oscuro de los micro-frontends: la duplicación de dependencias. ¿Alguna vez te has preguntado qué sucede con el tamaño total de tu bundle cuando divides un gran SPA en docenas de micro-frontends? En esta sesión compartiremos nuestro viaje compartiendo dependencias entre micro-frontends en monday.com para reducir el tamaño total del bundle en la página y aumentar el rendimiento.

This talk has been presented at JSNation 2025, check out the latest edition of this JavaScript Conference.

Sahar Brodbeker
Sahar Brodbeker
22 min
16 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Saar Becker discute los desafíos de los micro-frontends en monday.com, centrándose en el tamaño del bundle debido a la carga de React múltiples veces. La solución de intercambio en caliente v1 se introduce para abordar este problema compartiendo dependencias de manera eficiente. Las estrategias incluyen proporcionar la misma versión de React, gestionar dependencias compartidas a través de intercambios en caliente y optimizar la construcción de bundles creando bundles con nombres compuestos. La charla profundiza en revisar soluciones de intercambio en caliente, resolver problemas de dependencias indirectas y optimizar la construcción de bundles de dependencias para la preparación de producción.

1. Exploring Micro-Frontends Challenges

Short description:

Saar Becker recorre el viaje de monday.com en el intercambio de dependencias de micro-frontends. Rápido repaso sobre micro-frontends: dividir una gran aplicación de una sola página en aplicaciones más pequeñas. Los desafíos incluyen el tamaño del paquete debido a la carga de React varias veces.

Hola a todos. Mi nombre es Saar Becker, y hoy voy a guiarles a través de nuestro viaje en monday.com con el intercambio de dependencias entre nuestros micro-frontends. Vamos a repasar todos los desafíos que enfrentamos, todas las soluciones que intentamos y todas las lecciones que aprendimos en el camino. Pero antes de sumergirnos en los detalles de todo, hagamos un rápido repaso sobre qué son los micro-frontends.

Entonces, los micro-frontends son un patrón arquitectónico de front-end muy popular en el cual tomamos una gran aplicación de una sola página y la dividimos en aplicaciones más pequeñas. Como en este caso, tenemos el servicio A, el servicio B y el servicio C, cada uno siendo mantenido individualmente y desplegado a producción, y esto permite una mejor independencia para los equipos, un mejor alcance de nuestro sistema y un mejor aislamiento.

Pero con todas las cosas buenas que la arquitectura de front-end nos ofrece, también presenta algunos desafíos clave. Principalmente entre ellos está el tamaño del paquete. Así que lo que pueden ver aquí es que cuando teníamos una aplicación de una sola página, cargábamos React en la página solo una vez, porque existía en nuestro paquete solo una vez. Básicamente teníamos un paquete.

2. Addressing Micro-Frontends Bundle Size

Short description:

React cargado múltiples veces en micro-frontends lleva a un mayor tamaño de paquete y peor rendimiento. Compartir dependencias para mejorar el rendimiento; apuntando a la conformidad y al intercambio eficiente. Solución inicial v1 llamada solución de intercambio en caliente para un mejor rendimiento en micro-frontends.

solo una vez, porque existía en nuestro paquete solo una vez. Básicamente teníamos un paquete. Ahora, cuando tenemos micro-frontends, React está básicamente empaquetado en cada uno de nuestros micro-frontends, lo que significa que se carga en la página tantas veces como la cantidad de micro-frontends que tenemos. Así que, en este caso, cargamos React en la página tres veces. Y, hablando en términos generales, un tamaño de paquete más grande en general en la página, cuantos más activos descargamos y más cosas cargamos en la memoria, resulta en un peor rendimiento. Resulta en tiempos de red más largos, resulta en una huella de memoria más grande de nuestras pestañas, y eso es malo.

Así que, solo para poner esto en perspectiva con algunos números, cuando cargamos tres instancias de React en la página, añadimos alrededor de 15 kilobytes de código a la página. Y si cargamos, digamos, más micro-frontends con un paquete más grande, como MobX, por ejemplo, añadimos alrededor de 630 kilobytes a la página, lo cual no es nada despreciable, y afecta el rendimiento de la pestaña, como mencionamos. Entonces, ¿qué podemos hacer al respecto? Como habrán adivinado por el nombre de esta charla y la introducción, podemos compartir, porque compartir es cuidar. Así que nos propusimos crear una especificación de cómo vamos a compartir dependencias entre nuestros micro-frontends para permitir un mejor rendimiento en general en nuestra aplicación. Así que, primero y ante todo, queremos compartir tanto como sea posible, bajo la suposición de que cuantas más cosas compartamos, mejor será el rendimiento en general. Dicho esto, queremos asegurarnos de que estamos cumpliendo con la demanda de los micro-frontends, básicamente que estamos cumpliendo con diciembre, para que nada se rompa en la página.

Sí, eso es algo bastante grande, diría yo. Y eso incluye los dos puntos. Así que primero, queremos tener una instancia de una dependencia por versión principal. Así que digamos que tenemos dos micro-frontends, cada uno de ellos está usando una medida diferente de React, uno está usando React 16, y otro está usando React 18.

3. Optimizing Shared Dependencies

Short description:

Proporcionar la misma versión de React para micro-frontends; evitar paquetes de catálogo. Construir la primera solución v1, la solución de intercambio en caliente, excluye dependencias de los paquetes y utiliza objetos de ventana para referencias.

Pero digamos que tenemos dos micro-frontends diferentes que usan la misma versión principal de React. Digamos que ambos están usando React 18. Queremos poder proporcionarles la misma versión de React, la misma instancia de React, para ahorrar en el tamaño del paquete. Pero hay un pequeño inconveniente en eso, y queremos asegurarnos de que mientras proporcionamos React 18 para ambos, no estamos rompiendo ninguno de ellos. Así que digamos que uno necesita React 18.1.0 y el otro necesita React 18.3.0. No podemos dar al segundo micro-frontend React 18.1.0, porque entonces corremos el riesgo de romper su código en tiempo de ejecución.

Y finalmente, en nuestra especificación, no queremos incluir ningún paquete de catálogo. Y lo que queremos decir con paquetes de catálogo es que no queremos incluir ninguna dependencia que sea en el sentido de una biblioteca muy amplia que incluya muchas funciones o componentes. Tomemos lodash, por ejemplo, donde podrías tener un catálogo de muchos tipos diferentes de funciones, pero generalmente lo que termina sucediendo es que usas solo una pequeña subsección de esas funciones, y sería un poco un desperdicio cargar la totalidad de lodash, porque no puedes tener tree-shaking con nuestra solución.

Y será más efectivo simplemente empaquetar esas pocas funciones específicas en cada micro-frontend. Así que con esa especificación en mente, salimos a construir nuestra primera solución. Y vamos a repasar lo que hicimos en tiempo de construcción y lo que hicimos en tiempo de ejecución para todas nuestras soluciones. Así que la primera iteración de nuestra solución, la llamamos solución v1. La llamamos la solución de intercambio en caliente. Así que cómo funciona, vamos a comenzar con el proceso de construcción. Primero y ante todo, queremos excluir todas estas dependencias del paquete del micro-frontend. Así que en este caso, no queremos incluir el código fuente de React en nuestro paquete.

4. Managing Micro-Frontend Dependencies

Short description:

Creación de paquetes por dependencia con archivos de metadatos para micro-frontends. Gestión de dependencias compartidas, incluyendo intercambios en caliente para compatibilidad. Manejo de sub-dependencias creando nombres compuestos para dependencias.

Así que nos aseguramos de que en lugar de usar React y empaquetarlo en nuestro paquete de micro-frontend, creamos algún tipo de referencia a un objeto de ventana de algún tipo. En este caso, React 16. En segundo lugar, queremos usar esta lista cerrada de dependencias que ideamos. Incluye cosas como React, React DOM, MobX, MobX React, y así sucesivamente. Queremos usar esta lista y el paquete JSON del proyecto para crear un paquete por dependencia. Así que lo que hacemos durante la fase de compilación es revisar toda esta lista. Verificamos qué versión tiene instalada este micro-frontend y luego creamos un paquete dedicado para esta dependencia. En este pseudo código, creamos un paquete para React 18, que incluye todo su código fuente. Y también incluye un pequeño fragmento al final que expone el código fuente en la ventana bajo un nombre que incluye el nombre de la dependencia y su versión principal.

Así que una vez que tenemos eso, lo último es crear un archivo de metadatos para el micro-frontend que especifique qué dependencias compartidas y qué versión usa este micro-frontend. Así que en este ejemplo, especificamos que estamos usando React, por ejemplo, con la versión mínima de 18.1.0, que tiene el nombre global de React 18 y se carga en esta URL específica en nuestro CDN, cdn.com, y así sucesivamente. También incluye React DOM y todas las demás dependencias que tenemos en nuestra lista. Así que ahora que tenemos todo esto, excluimos cosas de nuestro paquete, creamos paquetes, los subimos a nuestro CDN, y tenemos el archivo de metadatos.

Ahora estamos listos para cargar este micro-frontend en producción, lo que incluye dos pasos básicos. En primer lugar, cuando vamos a cargar este micro-frontend en producción, queremos usar este archivo de metadatos para asegurarnos de que todo esté cargado para que este micro-frontend funcione. Así que antes de cargar realmente el código del micro-frontend, revisamos todas las dependencias compartidas que este micro-frontend necesita, y nos aseguramos de que todo esté cargado en la página. Eso es muy simple. Si no está cargado, lo vamos a cargar. Si está cargado y es compatible, que es el segundo punto, simplemente no hacemos nada. La única situación fuera de lo normal sería si la dependencia está cargada pero no es compatible con las necesidades de este micro-frontend. Así que, por ejemplo, si tomamos nuestro ejemplo anterior, digamos que tengo un micro-frontend que usa React 18.

5. Revising Micro-Frontend Hot-Swapping

Short description:

Cargando nuevas versiones de React, abordando problemas de sub-dependencias con nombres compuestos y revisando la solución para incluir dependencias globales.

Así que lo que hacemos es cargar React 18 una segunda vez, y esta vez React 18.3.0, y básicamente hacemos un intercambio en caliente, que es el homónimo de esta solución, lo que significa que cargamos React 18 de nuevo, y básicamente sobrescribimos el objeto window.react18, y ahora estamos usando React 18.3.0, que debería ser compatible, si Sanver lo permite, con la versión anterior, que es 18.1.0. Ahora, el primer problema con el que nos encontramos es un problema de sub-dependencias. Así que algunas dependencias en nuestra lista dependen de otras dependencias en nuestra lista, por ejemplo, MobX React depende de ambos MobX y React, que ambos existen en nuestra lista, lo que crea muchas combinaciones variables. Así que tomemos dos ejemplos, por ejemplo, digamos que uno de nuestros micro-frontends tiene MobX React 8 y usa React 16, y otro tiene MobX React 8, nuevamente la misma versión de MobX React, y usa React 18. En este caso, ambos micro-frontends van a usar la misma versión global de MobX React, que es MobX React 8, pero el problema es que MobX React bajo el capó necesita una versión muy específica de React, necesita React 18, para funcionar correctamente en tiempo de ejecución y no obtener muchos errores de React y pantallas rojas de la muerte. Entonces, ¿qué hacemos al respecto? Nuestra solución fue muy, muy simple. Queremos asegurarnos de que cuando creamos nuestras dependencias, nos aseguramos de que las creamos con nombres compuestos, y eso significa que cada dependencia también incluye en su nombre global todas sus sub-dependencias. Así que digamos que tenemos MobX React, que depende de React. Cuando añadimos la combinación de MobX React 8 y React 16, vamos a hacer React 16 guion bajo MobX React 8, y cuando tenemos MobX React 8 y React 18, vamos a hacer React 18 guion bajo, y así sucesivamente. Este es un ejemplo simplificado. Podríamos terminar con una situación donde tengamos como tres sub-dependencias de diferentes niveles y podríamos terminar con un nombre compuesto muy largo, pero eso básicamente asegura que los micro-frontends y sus sub-dependencias obtengan la referencia correcta en producción. Eso también nos obliga a actualizar el archivo de metadatos para reflejar este cambio e incluir sub-dependencias.

Así que esto cambia un poco nuestra solución. En lugar de construir con un nombre simplificado, usamos la misma lista con las mismas versiones que obtenemos de Package.json para crear el paquete con nombres compuestos por dependencia. Esta es la única diferencia. Todos los demás pasos en el proceso de construcción y en el proceso de tiempo de ejecución permanecen iguales, y eso fue todo para este problema, pero nos encontramos con un problema diferente. Lo que pensamos que sucedería cuando intercambiamos en caliente dependencias en producción es lo siguiente. Digamos que cargamos nuestro primer micro-frontend que usa React 18.1.0 y hace referencia a window.react18, y ahora digamos que cargamos un segundo micro-frontend que usa React 18.3.0. Como mencionamos antes, React 18.

1.0 no es compatible con 18.3.0, que es lo que nuestro segundo micro-frontend necesita. Así que cargamos React de nuevo y reemplazamos el puntero window.react18 para apuntar a nuestra nueva versión de React, así que cargamos React dos veces. Lo que esperábamos que sucediera es que ambos de nuestros micro-frontends iban a referenciar window.react18 en el código de tiempo de ejecución, y todo estaría genial, pero lo que realmente terminó sucediendo es que nuestro primer micro-frontend mantuvo la referencia de memoria a la primera instancia de React que cargamos en la página. Así que en lugar de usar la misma nueva instancia que nuestro segundo micro-frontend, siguió usando la instancia antigua, lo que significaba que no fue recolectada por el recolector de basura y en realidad cargamos React dos veces en la página, lo cual pierde un poco el sentido de lo que estamos tratando de hacer aquí. Así que esto nos llevó a revisar toda nuestra solución y básicamente crear una versión v2 de nuestra solución, que llamamos dependencias globales. Así que las dependencias globales son muy similares a la solución anterior que teníamos tanto en el proceso de construcción como en el proceso de tiempo de ejecución. La única diferencia es que durante el proceso de construcción de nuestros micro-frontends, también actualizamos algún tipo de archivo de metadatos global que tenemos, que mantenemos en el servidor. Y básicamente, este archivo de metadatos global contiene referencias a qué micro-frontend en nuestro sistema tenía la versión más alta por mayor de nuestras dependencias. Así que en este ejemplo simplificado, podemos ver que, por ejemplo, si necesitas usar React18 en tu micro-frontend, y no importa qué micro-frontend seas, sabemos que micro-frontend1 tiene la versión más alta de React18 posible en el sistema. Así que esta podría ser una situación en la que, por ejemplo, tenemos micro-frontend1 usando React18.7.0 y micro-frontend3, por ejemplo, usa React18.3.0. Cuando micro-frontend3 se carga en la página, va a usar la versión de React18 que es proporcionada por micro-frontend1 y existe en esta URL. De esta manera, tenemos una lista con todos los, incluyendo los nombres compuestos y todas nuestras dependencias por versión mayor a través de nuestro sistema.

6. Resolving Indirect Dependency Issues

Short description:

Manejo de dependencias indirectas con require resolve, gestión de múltiples versiones mayores en paquetes, y abordaje de dependencias anidadas.

Y eso es porque no está siendo usado directamente por los propios micro-frontends. Está siendo usado por un paquete diferente, React Popper en este caso. Así que eso significaba que nuestro proceso no había registrado que estaba siendo usado. Y de hecho, porque no está instalado en el package JSON de los micro-frontends, básicamente no creó un paquete dedicado para popperjs, y no lo incluyó en los metadatos de ese micro-frontend. Así que eso significaba que no estábamos obteniendo tanto como podíamos de nuestra solución, y no estábamos compartiendo tanto como pensábamos. Así que la solución aquí fue bastante simple. En lugar de usar el package JSON del proyecto para obtener la versión de las dependencias compartidas y determinar cómo crearlo, intentamos resolverlo usando require resolve, que es una función de node muy simple y ordenada que te da una ruta de tu dependencia que especificas. Esto nos lleva a la solución V versión 2.1, que es similar a V2. La única diferencia es que todavía usamos la lista, la lista cerrada que tenemos, pero en lugar de usar el package JSON del proyecto para obtener las versiones de las dependencias compartidas y crear nuestros paquetes para ellas, ahora usamos require resolve, que realmente nos da la versión instalada y todo está genial. Y en este punto, hemos estado funcionando con esta solución durante mucho tiempo, hasta que encontramos nuestro cuarto problema.

Así que nuestro cuarto problema fue que tenemos múltiples versiones mayores en el mismo paquete. Así que déjame pintar un cuadro para ti. Digamos que nuestro micro-frontend está usando MobX, está instalando MobX6, directamente, lo instala en su package JSON y lo usa para construir su almacén de datos. Y digamos que una de nuestras dependencias transitivas, en este caso, instalamos el paquete A, que usa el paquete B, que a su vez usa MobX5, por ejemplo. Lo que terminó sucediendo es que ambos usarían MobX6, porque nuestra solución, básicamente, si recuerdas, estamos revisando la lista cerrada, estamos haciendo require resolve, y vamos a obtener MobX6. Así que el paquete B tendría una referencia para usar MobX6 en producción, lo que terminó, lo que nos dejó con referencias rotas en producción, lo cual obviamente fue bastante malo. Así que nuestra solución para eso fue bastante simple. Queríamos crear, en realidad no tan simple, queríamos crear referencias a versiones mayores por importación en lugar de usar el package JSON del proyecto. Así que cómo se ve eso en nuestro proceso de construcción, esto afectó mucho nuestro proceso de construcción.

Así que en lugar de revisar nuestra lista cerrada, nuestra lista codificada, y crear paquetes por dependencia instalada, lo que hacemos ahora es que cuando construimos nuestro paquete principal, básicamente, recordamos qué dependencias, cuál de las dependencias en la lista usamos, y de dónde se usó. Así que cada vez que encontramos un uso de una de nuestras dependencias compartidas, básicamente intentamos resolverlo desde esa ruta específica. Así que digamos que encontramos el uso en nuestro paquete principal, hacemos require.resolve desde esa ruta específica. Y digamos que lo encontramos de nuevo en algún tipo de dependencia transitiva, hacemos require.resolve desde esa ruta. Así que eso podría dejarnos con dos usos de la misma dependencia compartida, pero están siendo usados desde diferentes rutas en nuestros módulos node, lo que podría significar que están siendo usados con diferentes versiones mayores. Así que ahora que tenemos todas estas referencias que creamos durante el proceso de compilación de nuestro paquete principal, ahora podemos usar esa misma memoria para crear un paquete por dependencia con nombre compuesto por versión mayor. Así que de nuevo, cómo se vería eso, afectaría el archivo de metadatos de nuestro micro-frontend, que ahora podría incluir múltiples versiones mayores por paquete, por dependencia compartida, pero ahora tenemos referencias funcionales en producción, lo cual es significativamente más importante. Nuestro quinto y último problema que encontramos son las dependencias anidadas. Así que el problema que tenemos es que podríamos tener algunas dependencias en nuestra lista que no están siendo usadas directamente por nuestros micro-frontends. Así que digamos, por ejemplo, que tenemos popperjs slash core, que está siendo usado por react-popper. Así que lo que terminó sucediendo es que cuando revisamos el paquete principal de nuestros micro-frontends, no encontramos ningún uso de popperjs slash core.

7. Optimizing Dependency Bundle Building

Short description:

Aplicando memoria de dependencias de forma recursiva, creando paquetes con nombres compuestos para cada versión principal, asegurando la preparación para producción.

Nos encontramos con ellos solo cuando construimos el paquete para react-popper, que también está en nuestra lista. Así que eso significaba que si solo miramos el paquete principal de nuestros micro-fondants y solo recordamos qué dependencias usamos cuando construimos ese paquete, terminamos con referencias faltantes. Así que en este caso, popperjs slash core. Así que la solución para eso fue aplicar esa misma lógica de construcción de dependencias, esa misma memoria de recordar lo que usamos recursivamente para cada uno de nuestros paquetes de dependencias, así como nuestro paquete principal.

Así que lo que eso parece en términos de nuestro proceso, en lugar de hacer todo este proceso de recordar solo para nuestro paquete principal, aplicamos la siguiente lógica. Mientras todavía tengamos algunas dependencias por construir, queremos usar esa memoria para crear un paquete por dependencia con un nombre compuesto por versión principal, y cuando construimos ese paquete, recordamos lo que usamos. Así que este proceso básicamente asegura que sigamos construyendo nuevos paquetes de dependencias. Obviamente, para aquellos que aún no hemos construido. Ahora tenemos todos nuestros paquetes listos para usar en producción. Todos los demás pasos en el proceso de construcción y el proceso de ejecución permanecen prácticamente iguales.

Eso es básicamente todo. Esa es la solución con la que terminamos hoy, en Monday. Creo que una de las cosas que más temíamos era que íbamos a tener rupturas en producción. Por supuesto, todo esto parece muy delicado y propenso a romperse. Así que tengo que decir que durante los tres años que hemos estado ejecutando esta solución, no hemos tenido ningún problema en términos de Sanver o paquetes que no cumplan o se rompan o algo así. Es importante notar que implementamos muchos interruptores de apagado y mecanismos de seguridad alrededor de esta solución. También se lanzó como una solución experimental a todos nuestros micro front ends. Lo implementamos de manera lenta y gradual durante el transcurso de aproximadamente seis meses o algo así. Y ahora es el predeterminado en todos nuestros micro front ends. Y está funcionando muy bien.

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

Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Entendiendo la Arquitectura Fiber de React
React Advanced 2022React Advanced 2022
29 min
Entendiendo la Arquitectura Fiber de React
Top Content
This Talk explores React's internal jargon, specifically fiber, which is an internal unit of work for rendering and committing. Fibers facilitate efficient updates to elements and play a crucial role in the reconciliation process. The work loop, complete work, and commit phase are essential steps in the rendering process. Understanding React's internals can help with optimizing code and pull request reviews. React 18 introduces the work loop sync and async functions for concurrent features and prioritization. Fiber brings benefits like async rendering and the ability to discard work-in-progress trees, improving user experience.
Componentes de Full Stack
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Componentes de Full Stack
Top Content
RemixConf EU discussed full stack components and their benefits, such as marrying the backend and UI in the same file. The talk demonstrated the implementation of a combo box with search functionality using Remix and the Downshift library. It also highlighted the ease of creating resource routes in Remix and the importance of code organization and maintainability in full stack components. The speaker expressed gratitude towards the audience and discussed the future of Remix, including its acquisition by Shopify and the potential for collaboration with Hydrogen.
Thinking Like an Architect
Node Congress 2025Node Congress 2025
31 min
Thinking Like an Architect
Top Content
In modern software development, architecture is more than just selecting the right tech stack; it involves decision-making, trade-offs, and considering the context of the business and organization. Understanding the problem space and focusing on users' needs are essential. Architectural flexibility is key, adapting the level of granularity and choosing between different approaches. Holistic thinking, long-term vision, and domain understanding are crucial for making better decisions. Effective communication, inclusion, and documentation are core skills for architects. Democratizing communication, prioritizing value, and embracing adaptive architectures are key to success.
De Monolito a Micro-Frontends
React Advanced 2022React Advanced 2022
22 min
De Monolito a Micro-Frontends
Top Content
Microfrontends are considered as a solution to the problems of exponential growth, code duplication, and unclear ownership in older applications. Transitioning from a monolith to microfrontends involves decoupling the system and exploring options like a modular monolith. Microfrontends enable independent deployments and runtime composition, but there is a discussion about the alternative of keeping an integrated application composed at runtime. Choosing a composition model and a router are crucial decisions in the technical plan. The Strangler pattern and the reverse Strangler pattern are used to gradually replace parts of the monolith with the new application.

Workshops on related topic

IA a demanda: IA sin servidor
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
IA a demanda: IA sin servidor
Top Content
Featured WorkshopFree
Nathan Disidore
Nathan Disidore
En esta masterclass, discutimos los méritos de la arquitectura sin servidor y cómo se puede aplicar al espacio de la IA. Exploraremos opciones para construir aplicaciones RAG sin servidor para un enfoque más lambda-esque a la IA. A continuación, nos pondremos manos a la obra y construiremos una aplicación CRUD de muestra que te permite almacenar información y consultarla utilizando un LLM con Workers AI, Vectorize, D1 y Cloudflare Workers.
Micro Frontends with Module Federation and React
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Top Content
Workshop
Alex Lobera
Alex Lobera
¿Alguna vez trabajaste en una aplicación monolítica de Next.js? Yo sí, y escalar una gran aplicación de React para que muchos equipos puedan trabajar simultáneamente no es fácil. Con micro frontends, puedes dividir un monolito de frontend en piezas más pequeñas para que cada equipo pueda construir y desplegar de manera independiente. En este masterclass, aprenderás cómo construir grandes aplicaciones de React que escalen utilizando micro frontends.
Masterclass de alto rendimiento Next.js
React Summit 2022React Summit 2022
50 min
Masterclass de alto rendimiento Next.js
Workshop
Michele Riva
Michele Riva
Next.js es un marco convincente que facilita muchas tareas al proporcionar muchas soluciones listas para usar. Pero tan pronto como nuestra aplicación necesita escalar, es esencial mantener un alto rendimiento sin comprometer el mantenimiento y los costos del servidor. En este masterclass, veremos cómo analizar el rendimiento de Next.js, el uso de recursos, cómo escalarlo y cómo tomar las decisiones correctas al escribir la arquitectura de la aplicación.
Microfrontends con Module Federation y Angular
JSNation Live 2021JSNation Live 2021
113 min
Microfrontends con Module Federation y Angular
Workshop
Manfred Steyer
Manfred Steyer
Cada vez más empresas eligen Microfrontends. Sin embargo, no son fáciles de implementar. Afortunadamente, Module Federation introducido con webpack 5 ha iniciado un cambio crucial de dirección.
En este masterclass interactivo, aprenderás de Manfred Steyer, Angular GDE y Colaborador de Confianza en el equipo de Angular, cómo planificar e implementar arquitecturas de Microfrontend con Angular y el nuevo Module Federation de webpack. Hablaremos sobre compartir bibliotecas y conceptos avanzados como manejar desajustes de versión, Module Federation dinámico e integración en monorepos.
Después de los ejercicios individuales, tendrás un estudio de caso que podrás utilizar como plantilla para tus proyectos. Este masterclass te ayuda a evaluar las opciones individuales para tus proyectos.
Prerrequisitos:Debes tener algo de experiencia con Angular.