Micro-Frontends con React y Federación de Módulos Vite

¡Hola a todos! Bienvenidos a esta charla, Microfrontends con React y Federación de Módulos con Vitz. Me gustaría, con Microfrontends... Sé que esta es una Conferencia Avanzada de React, pero me gustaría compartir con ustedes la arquitectura de Microfrontends para aquellos que realmente no la conocen bien en profundidad.

Entonces, Microfrontends es más o menos lo que son los microservicios, pero para el front-end. Si tenemos un monolito, podemos dividir la parte del servidor en microservicios para gestionar mejor los endpoints y también las características, pero en este caso particular, el front-end es un monolito. Así que podemos dividir el monolito, el monolito del front-end en muchos microfrontends, y eso es más o menos la arquitectura. Podemos tener varios dominios verticales, por lo que podemos tener un frontend en React, otro en Angular, y por ejemplo, otro en Vue. Y teóricamente, microfrontends es ambos, por lo que la parte del servidor y también la parte del frontend. Pero, ¿cómo podemos dividir el monolito? Así que podemos dividir nuestra aplicación, la aplicación frontend, de diferentes maneras.

Tenemos una división vertical, por lo que un microfrontend para cada página o varias páginas. El equipo azul se encarga de la página de inicio, y el equipo rojo gestiona el proceso de pago. O podemos dividir de manera horizontal. El equipo azul es el propietario del menú y la barra de aplicaciones, y el rojo, el verde y el rojo están gestionando los paneles de control. Así que esto es más o menos cómo podemos dividir el monolito de manera vertical y horizontal. Pero, ¿necesitamos, necesito este tipo de arquitectura?

Estas son algunas de las empresas que están utilizando micro frontend, y como puedes notar, estas son grandes empresas. Así que esta arquitectura nace para dividir la aplicación frontend y gestionar fácilmente la base de código en varios equipos. Pero si tengo una aplicación mediana o pequeña, puedo usar este concepto, esta arquitectura para el patrón Strangler. Así que si tengo una aplicación heredada, puedo reemplazar partes de mi aplicación para renovarla. Así que si tienes una casa y quieres, por ejemplo, renovar tu jardín, puedes arrancar todo el viejo jardín y poner uno nuevo. Así que esa es más o menos la idea que podemos aplicar a nuestra aplicación heredada. Así que hay muchos desafíos en este proceso. Uno de ellos es el aspecto y la sensación. Así que aquí puedes ver que es una casa moderna. Así que si entramos en esta casa moderna, visitamos un poco la ubicación. Podemos ver la cocina que es una cocina moderna. Podemos ir a la sala de estar. Pero si vamos al baño, y entramos en el dormitorio, y vemos este estilo diferente, es un poco extraño. Así que puedes imaginar este concepto en nuestra aplicación. Entramos en la página de inicio, y es realmente genial. Vamos a la página del producto, y también es genial.

Vamos a la caja, y podemos ver un estilo completamente diferente. Por lo tanto, el aspecto y la sensación de la aplicación deben ser los mismos para evitar este tipo de situaciones problemáticas o extrañas. Entonces, necesitamos compartir un estilo a través de toda la aplicación, ¿pero cómo podemos compartir estos estilos?

Entonces, podemos usar Vanilla CSS. Entonces, tenemos Microfrontend A y Microfrontend B. Simplemente podemos inyectar la hoja de estilo dentro de la página y podemos definir dos clases, card title. Entonces, Microfrontend A tiene un card title con el color negro y tenemos Microfrontend B con el mismo nombre con un color rojo. Al final, si inyectamos en este orden específico las hojas de estilo, tenemos el resultado es card title rojo, porque el último CSS gana y sobrescribe el otro. Entonces, ¿cómo podemos evitar en este tipo de situación este problema?

Podemos usar el paquete npm. Esto es para webpack, es post CSS prefix wrap. Básicamente, lo que está haciendo, es envolviendo nuestro CSS y poniendo un prefijo para todo el CSS para evitar estos conflictos. Es bastante usado, más de 19,000 de descargas, descargas semanales en npm. Pero si tu aplicación está en Vite, puedes usar post CSS prefixer. Como puedes ver aquí, estamos definiendo el selector, y la salida es prefix underscore underscore selector. Entonces, está envolviendo para nosotros en el proceso de construcción, está envolviendo el CSS y nos da la posibilidad de definir un CSS sin chocar con otro CSS de otros microfrontends.

Tenemos la posibilidad independiente de definir nuestra clase y usarla. O podemos usar otra forma es usar CSS modules. Entonces, podemos definir este tipo de archivo, así que card.module.css, definimos nuestro CSS, así card background color black. Luego podemos importar este module.css en nuestro componente React. Y podemos usar este objeto styles.card. Entonces, esta tarjeta es básicamente nuestro CSS, podemos inyectarla en el JSX de nuestro componente React. Y la salida del proceso de construcción será más o menos así. Entonces, card este es el nombre del módulo. Card es el nombre principal del CSS. Y tenemos este ID único que evita conflictos con el otro CSS. Y esto es de alcance local. Entonces, no tenemos un problema con otras propiedades de carrito, carrito CSS en los otros archivos.

Otra forma de gestionar el estilo es CSS en JS. Es un estilo de alcance local, como el modelo CSS que vimos antes, así que evitamos conflictos. Es un buen enfoque para la co-ubicación porque podemos co-ubicar el CSS en nuestro archivo JavaScript o archivo TypeScript, así en nuestro componente React. El CSS está realmente cerca de nuestro componente, por lo que es fácil gestionar el estilo y las demás cosas.

Puedes usar variables JavaScript en estilos, así que si tienes una variable específica para padding o lo que sea, puedes usar esta variable en el CSS y es realmente útil. Hay algunos costos. La legibilidad del código principal, como el módulo CSS, en el DevTool de Chrome, o tu navegador, es un poco difícil, porque si recuerdas en el módulo CSS, tenemos este hash específico, por lo que necesitamos mirar en el DevTool para entender mejor nuestro CSS. Y este CSS específico en JS agrega una sobrecarga en runtime. Entonces, cuando nuestra aplicación está en ejecución, está agregando un poco de carga para nuestra aplicación.

Otro gran problema a resolver en este tipo de architecture es compartir el estado. Así que tenemos múltiples formas de compartir el estado. Podemos usar un evento personalizado. Así que un microfrontend puede llamar a eventos personalizados, y otro puede escucharlos. Esta es una implementación realmente básica, y estamos usando la API Vanilla del navegador. Así que es realmente bueno. Podemos usar el canal de transmisión. Y este enfoque nos permite usar Win, pasar la información a través de ventanas, pestañas, iframes. Así que si tenemos algunos iframes, es un enfoque realmente agradable.

Podemos tener un administrador de estado compartido. Por ejemplo, podemos tener un administrador de estado ZooStand. Y podemos compartir la instancia de este ZooStand a través de nuestros microfrontends. Ten en cuenta que en tu architecture, necesitas compartir la menor información posible, porque puedes compartir como el tema u otras cosas. Pero no compartas demasiado porque el enfoque básico para los microfrontends es desacoplar, el despliegue y también el desarrollo. Así que si compartes demasiado con otros microfrontends, por supuesto, estás acoplando los microfrontends, y es difícil terminar con este problema.

Así que tenemos la última posibilidad, podemos tener una implementación personalizada de PubSub, así podemos crear nuestra propia implementación para gestionar el estado a través de nuestros microfrontends. Así que aquí hay un pequeño fragmento. Tomé este pequeño fragmento de este artículo de mi amigo Florian Rappel. Así que gracias. Me gustaría compartir y mirar este fragmento contigo. Así que este es el código de la shell de la aplicación, la shell de la aplicación que está cargando todos los microfrontends. Así que estamos definiendo en la ventana una función de publicación, una función de suscripción y una función de cancelación de suscripción y luego tenemos 11 oyentes para PubSub. En el micro frontend A básicamente podemos suscribirnos a este tema micro frontend A, y en el micro frontend B podemos publicar algo en este tema específico. Así que si llamamos a window.publish, estamos enviando un evento con detalle y tema y mensaje. Con este truco particular de una variable estamos llamando al final a los manejadores de temas porque el window.subscribe() aquí está guardando todas las funciones de mensaje. Así que cuando llega un mensaje, alguien publica algo en un tema, en el manejador de temas estamos recorriendo todos estos manejadores de temas y estamos llamando a la función. Así que finalmente al final de este proceso, el microfrontend A es capaz de obtener su información. No me gusta mucho esta implementación, es una implementación simple y puedes empezar desde ella, por eso decidí poner este fragmento en las diapositivas. No me gusta porque el microfrontend B necesita saber, digamos, que hay otro microfrontend y como mencionamos antes, nos gustaría desacoplar lo más posible nuestro proceso. Y otra cosa que no me gusta mucho es el objeto window, así que estamos usando la ventana como un objeto compartido a través de toda nuestra architecture.

Pero como mencioné antes, para iniciar un enfoque mínimo y luego podemos agregar la característica y otra característica, es realmente genial.

Bueno, entonces podemos componer esta architecture de muchas maneras. Podemos componer la architecture en el lado del servidor, por lo que el servidor está obteniendo toda la información y está creando nuestra aplicación para nosotros porque al final, la aplicación siempre es una, por lo que el usuario final pasa por una aplicación. Y también podemos tener la composición de borde, por lo que para el Lambda o CDN, podemos componer todos los micro-frontends y podemos tener la composición del cliente.

Entonces, en esta charla, me gustaría entrar en la composición del cliente y para la composición del cliente, tenemos una federación de módulos. Entonces tenemos un Webpack. Y en agosto de 2022, Zach Jackson, creo que el principal chico que está buscando la federación de módulos, lanzó al código abierto, este modelo específico. Así que trabajé en programación en pareja con mi amigo, Manfred Steyer. Y con esta posibilidad particular que Zach Jackson nos dio al abrir el código de la biblioteca, creamos la posibilidad de hacer una federación de módulos con Vite. Entonces, el otro principal bundler que existe. Entonces Manfred creó esta capa de federación nativa. Entonces, es una capa de una API nativa, y también creó la implementación de angular encima de esta capa. Yo creé una federación de módulos de propósito general Vite. Y puedes usar esta biblioteca para Svelte, React, Vue o lo que sea. Y ahora también podemos usar la federación de módulos con Vite. Entonces, esto es realmente, realmente impresionante. Creé esta biblioteca en mi perfil de GitHub. Y Jack Jackson vio mi trabajo y decidió mover todo el código a la organización de federación de módulos. Entonces, si vas a la Federación de Módulos slash Vite, encontrarás este plugin. También puedes encontrar la implementación para React y muchos otros marcos. Así que archivé mi proyecto y moví todo el código allí. Entonces, ¿cómo podemos compartir las dependencias? Entonces, otra gran cosa en la architecture es compartir las dependencias. Y afortunadamente, la implementación de la Federación de Módulos Vite es realmente similar a la de Webpack. Entonces, la original. Entonces, puedes mezclar y combinar la Federación de Módulos con Vite y la Federación de Módulos con Webpack. Y necesitas definir para Vite, necesitas definir una configuración especial para que puedas esperar la función de federación. Porque un plugin en Vite es más o menos una función. Puedes obtener esta función de la Federación de Módulos slash Vite. Puedes y necesitas definir la configuración y algunas otras opciones.

¿Y qué es esta configuración? Esta configuración es realmente, realmente similar a la de Webpack. Entonces puedes, esta es una configuración para un remoto. que se carga desde nuestra aplicación shell. Así que puedes definir un nombre, puedes exponer el componente que te gustaría compartir con la aplicación principal. Así que este es básicamente tu micro frontend. Y también puedes compartir las bibliotecas. Así que aquí estamos compartiendo todas nuestras bibliotecas, pero puedes definir una por una una biblioteca específica. Así que si dos micro frontends necesitan la misma biblioteca y la misma versión, podemos evitar descargar dos veces la misma base de código, pero podemos reutilizar la única que tenemos en caché. Y básicamente podemos mantener alguna otra biblioteca que no queremos. Así que en este caso específico, mantenemos react-dom slash server y server.node.

Vale. Eso es todo. Soy un desarrollador de FoodStack para clarinete. Puedes encontrarme en X, y mi nombre de usuario es georgio underscore boa. O puedes encontrarme en LinkedIn con mi nombre y apellido. Soy un desarrollador de código abierto en mi tiempo libre. Y actualmente estoy trabajando duro en el marco QUIC. Desde 2022 trabajo con QUIC. Soy colaborador y mantenedor principal. También estoy impulsando en la base de código principal. Así que si te gustaría o si estás interesado en mirar a QUIC, por favor echa un vistazo porque creo que será un gran marco para el futuro. Gracias por escuchar y que tengas una buena masterclass. Adiós.