Libertad de plataforma con Micro-frontends

Rate this content
Bookmark
Slides

¿Pueden las aplicaciones de React y TypeScript ejecutarse en diferentes plataformas (carcasas de aplicaciones) con cambios mínimos en el código fuente? ¡Sí! con la estrategia de Micro-frontend en la arquitectura Multiplying. Presentaré una nueva dimensión de Micro-frontend que allanó el camino para desacoplar los componentes de una aplicación React monolítica más grande utilizando un nuevo marco llamado arquitectura Multiplying. El marco es altamente flexible y escalable para el desarrollo de código, y también ayuda a los negocios y a la comunidad.

31 min
24 Oct, 2022

Video Summary and Transcription

Esta charla explora las estrategias de Microfrontend y los beneficios de usar la arquitectura Multiplying para implementar aplicaciones en múltiples plataformas. Se discuten los conceptos de libertad de plataforma, implementación de Microfrontend y Backend for Frontend (BFF). La charla también destaca los desafíos de depuración y estilización en aplicaciones de Microfrontend más grandes e introduce la arquitectura Multiplying como solución. Se explican los elementos principales de la arquitectura Multiplying y cómo permite la comunicación entre diferentes pilas tecnológicas. La charla concluye mostrando el uso de listas incrustadas, módulos federados y configuración de Webpack para lograr un intercambio eficiente de código y implementación en múltiples distribuciones.

Available in English

1. Platform Freedom with Microfrontends

Short description:

Esta charla te llevará a través de las estrategias de Microfrontend, los problemas que resuelve la arquitectura de Microfrontend, un nuevo marco de trabajo que se construyó sobre las estrategias de Microfrontend y cómo esta multiplicación del nuevo marco de trabajo nos ayudó a implementar nuestras aplicaciones en múltiples sistemas distribuidos. Quería compartir la experiencia que tuvimos y las lecciones que aprendimos al implementar ciertos casos de uso. Comenzamos con microamistades y luego introdujimos un marco de trabajo llamado la arquitectura de multiplicación. Y tuvimos ciertos aprendizajes de ello. Y finalmente, con la colaboración de las estrategias de microamistad, junto con la arquitectura de micro-multiplicación, logramos nuestros resultados. En primer lugar, me gustaría abordar mi tema de libertad de plataforma con microamistad y quiero enfatizar lo que quiero decir con el término libertad de plataforma. Todos sabemos que la tecnología web domina completamente la industria del desarrollo de software en este momento. Y la tecnología web se ha convertido en la opción predeterminada para la mayoría de los desarrolladores y las empresas que desean desarrollar una aplicación o un producto para su caso de uso.

Hola, y bienvenidos a todos a la charla, Libertad de plataforma con Microfrontends. Esta charla te llevará a través de las estrategias de Microfrontend, los problemas que resuelve la arquitectura de Microfrontend, un nuevo marco de trabajo que se construyó sobre las estrategias de Microfrontend y cómo esta multiplicación del nuevo marco de trabajo nos ayudó a implementar nuestras aplicaciones en múltiples sistemas distribuidos.

Antes de entrar en el tema, permítanme presentarme, soy Saravan Balaji Srinivasan, trabajo como ingeniero de software senior en Red Hat como desarrollador full stack con un enfoque principalmente en las tecnologías JavaScript. Trabajo en áreas donde construimos herramientas para productos de automatización empresarial y especificaciones de flujos de trabajo sin servidor, etc. Eso es todo sobre mí. Y volvamos al tema.

Me gustaría comenzar con la historia de Red Hat. Quería llevar esta charla de tal manera que pudiera compartir la experiencia que tuvimos y las lecciones que aprendimos al implementar ciertos casos de uso. Hace algún tiempo, teníamos un caso de uso en el que queríamos implementar ciertas herramientas que construimos para ejecutar en varias plataformas, y queríamos reutilizar los componentes que creamos en React JS. Esa fue la idea detrás de la historia. Comenzamos con microamistades y luego introdujimos un marco de trabajo llamado la arquitectura de multiplicación. Tuvimos ciertos aprendizajes de ello. Y finalmente, con la colaboración de las estrategias de microamistad, junto con la arquitectura de micro-multiplicación, logramos nuestros resultados. La próxima diapositiva mostrará cómo lo logramos. En primer lugar, me gustaría abordar mi tema de libertad de plataforma con microamistad y quiero enfatizar lo que quiero decir con el término libertad de plataforma. Todos sabemos que la tecnología web domina completamente la industria del desarrollo de software en este momento. Y la tecnología web se ha convertido en la opción predeterminada para la mayoría de los desarrolladores y las empresas que desean desarrollar una aplicación o un producto para su caso de uso. Esto se debe a que la tecnología web tiene una base sólida. Tiene estándares sólidos, patrones, técnicas. Y las arquitecturas de la tecnología web están evolucionando muy rápido a lo largo del tiempo. También tiene un ecosistema rico. Cuando hablamos de tecnologías web, no podemos ignorar JavaScript. Ahora, en este momento, JavaScript está en todas partes. Aunque inicialmente comenzó como un lenguaje de scripting para un propósito pequeño, ahora ha evolucionado a lo largo del tiempo y puedes encontrar JavaScript en todas partes en tu navegador. En el navegador de tu computadora portátil, en tus teléfonos móviles, en tu PWA, en tus servidores, en todas partes puedes ver JavaScript ahora. Además, después de la introducción de TypeScript, personalmente siento que, debido a su comportamiento de verificación de tipos estáticos, la percepción de los desarrolladores sobre la tecnología web ha cambiado por completo. Personas como yo que comenzaron mi carrera en la tecnología Java, como desarrollador de Java, después me convertí en ingeniero de JavaScript y luego, para la tecnología web y todo eso, como ingeniero full stack ahora, comencé a gustar la tecnología web después de aprender TypeScript, porque mi código es totalmente seguro en cuanto a tipos. También enfatizaré que el navegador está en todas partes en este momento, ¿verdad? Puedes tener tu navegador en tu computadora portátil, puedes tenerlo en tu móvil y servidores, y PWA, etc.

2. Estrategias de Plataforma y Microfrontend

Short description:

El objetivo es ejecutar aplicaciones en múltiples plataformas como VS Code, navegadores y GitHub. La tecnología web ha evolucionado rápidamente, comenzando con la arquitectura evolutiva, seguida de microservicios y sin servidor. Las estrategias de microfrontend se utilizan para descomponer aplicaciones monolíticas en aplicaciones frontend más pequeñas y entregables de forma independiente. Cada microfrontend puede ser propiedad y mantenida por un equipo individual y autónomo.

Ahora, el navegador no es solo una ventana para acceder a Internet. Por lo tanto, puedes mostrar tu interfaz de usuario gráfica en cualquier lugar de tu navegador y puede ejecutarse en cualquier plataforma. Entonces, lo que quiero decir con plataforma en mi tema es que la aplicación debe ejecutarse en plataformas. En nuestro caso de uso, las plataformas que queríamos lograr son ejecutar nuestras aplicaciones en el IDE de VS Code como una extensión. Y debe ejecutarse en el navegador como una extensión. Tal vez en el caso de Chrome, debe ejecutarse como una extensión de Chrome. Y en el caso de Firefox, debe ejecutarse como una extensión de Firefox. Y el mismo conjunto de código, el mismo conjunto de componentes debe ejecutarse en la aplicación web y también en GitHub como una extensión de GitHub. Este fue el objetivo final que queríamos lograr. Para ello, quiero que mis dos enlaces se ejecuten en VS Code, GitHub, navegador como una aplicación web y también en el...

Al implementar esto, analizamos la arquitectura que tenemos en la tecnología web. La tecnología web, como mencioné en la diapositiva anterior, está creciendo muy rápido. Comenzando con la arquitectura evolutiva, que admite cambios incrementales guiados como un primer principio en múltiples dimensiones. Luego viene el rompedor de camino, que llamamos microservicios, que permite que el backend se divida en microservicios más pequeños y desacoplados que pueden ejecutarse de forma independiente. Y luego viene la palabra de moda en este momento, que es sin servidor, donde el backend es un servicio. Puedes implementar tu función en un servidor y pagar solo por la cantidad de veces que se llama la función y el tiempo que se utiliza. Puedes pagar solo por eso en lugar de poseer todo el servidor. Y finalmente, tenemos el término microfrontend, que nuevamente, desde donde pensamos en implementar estrategias de microfrontend para un caso de uso. Esto me lleva a la siguiente diapositiva nuevamente.

Supongo que la mayoría de ustedes ya han probado algo en las estrategias de microfrontend o tal vez hayan escuchado el término, pero aún así me gustaría repasar las estrategias de microfrontend para las personas que aún no lo han aprendido. Considera si tienes una aplicación frontend monolítica más grande, cuando digo monolítica, es una gran cantidad de aplicación que es mantenida por un gran equipo y que tiene una gran cantidad de código. Cuando tienes este tipo de escenario, obviamente estás sujeto a muchos errores, problemas de producción, errores que no se pueden solucionar fácilmente. Para abordar este problema, los desarrolladores de todo el mundo comenzaron a pensar en una solución para dividir esta aplicación monolítica en piezas más pequeñas. Esto sucedió hace unos cinco o seis años. En ese momento, los microservicios estaban evolucionando mucho en las tecnologías de backend, por lo que los desarrolladores frontend querían tener este conjunto similar de estrategias también en el frontend. Fue entonces cuando se introdujo el término microfrontend. Así es como evolucionó el microfrontend. Según Kam Jackson, un arquitecto reconocido, la arquitectura de microfrontend es un estilo arquitectónico donde las aplicaciones frontend entregables de forma independiente se componen en un todo mayor. Simplemente, puedo decir que se trata de dividir una aplicación monolítica en microfrontends más pequeños, y cada microfrontend puede ser propiedad de un equipo individual y autónomo. Pueden tener sus propias implementaciones, sus propios ciclos de lanzamiento, pueden mantener sus propios microfrontends sin depender de otros microfrontends u otros equipos.

3. Implementación de Microfrontend y BFF

Short description:

Este ejemplo demuestra cómo se puede implementar un microfrontend descomponiendo una interfaz de usuario en componentes más pequeños, cada uno mantenido por un equipo separado. Los microfrontends están contenidos dentro de una única aplicación contenedor, que toma las decisiones de renderizado. También discutimos los conceptos de monolito, microservicios y microfrontend, y cómo el frontend puede desacoplarse en microfrontends más pequeños. Otro concepto que evolucionó con el microfrontend es BFF (Backend for Frontend).

Este ejemplo te dará una idea de cómo se verá un microfrontend. Como mencioné en mis diapositivas anteriores, trabajo en un equipo donde construimos herramientas para productos de automatización empresarial. DMN es una de esas herramientas, que es una representación gráfica de las decisiones y reglas comerciales. Aquí puedes ver un tipo de gráfico que muestra el conjunto de reglas y decisiones comerciales. Descomponemos esta interfaz de usuario en múltiples microfrontends. Por ejemplo, podemos descomponer esta interfaz de usuario en múltiples microfrontends. Considerando el encabezado, puedes descomponerlo en un microfrontend más pequeño, que puede ser mantenido por un equipo separado. Imagina si tienes un sitio de comercio electrónico o una aplicación más grande donde el encabezado en sí mismo es una gran cantidad de componentes de React. Imagina que puedes tener tu barra de búsqueda, tu logotipo, tu inicio y cierre de sesión de perfil, y múltiples menús desplegables en el encabezado. Todo esto constituye un gran conjunto de componentes que residen en el encabezado. Definitivamente califica como un microfrontend separado. Y esto podría ser mantenido por un equipo separado. Y también aquí, volviendo a este editor, en el centro, tenemos el editor, que se menciona como un componente, mi microfrontend C, que puede ser mantenido por un equipo separado. Y nuevamente, a la izquierda, tenemos una especie de navegador, que te permite navegar a través de los nodos del diagrama que tenemos aquí, nuevamente, que podría ser mantenido por un microfrontend separado. Todos estos microfrontends están contenidos dentro de una única aplicación contenedor. Y esa aplicación contenedor toma las decisiones principales para renderizar los microfrontends.

Esta diapositiva te dará una idea de los tres términos que hemos discutido hasta ahora, monolito, microservicios y microfrontend. En el caso de una aplicación web monolítica, tienes tu frontend, tienes tu backend y el backend está conectado a la fuente de datos. Cuando hay una solicitud desde el frontend, llega al backend y el backend se conecta con la fuente de datos y obtiene los datos de la fuente de datos y los pasa al frontend. Es un enfoque directo que hemos estado siguiendo a lo largo de los años. Después de la introducción de los microservicios, hemos desacoplado por completo el backend en microservicios más pequeños. Y entre el frontend y los microservicios, hay una capa llamada Capa de Puerta de Enlace de API, que toma las decisiones basadas en la solicitud que viene desde el frontend. Y pasa la solicitud al microservicio específico que puede manejar esa solicitud en particular. Y cada microservicio tendrá su propia fuente de datos. Y combinando este microservicio junto con el microfrontend, incluso en este punto, el frontend está desacoplado en microfrontends más pequeños, y tenemos la Capa de API en el medio. Y luego tenemos los microservicios nuevamente. Y luego cada microservicio tiene su propia fuente de datos. Esta diapositiva te llevará a través de otra emocionante arquitectura o concepto que

4. Understanding Microfrontend Architecture

Short description:

BFF actúa como intermediario entre el microfrontend y el microservicio, reduciendo el esfuerzo del microfrontend. Los microfrontends están conectados directamente al contenedor, con decisiones importantes tomadas por el contenedor. Hay dos estrategias de integración: integración en tiempo de ejecución e integración en tiempo de compilación. La integración en tiempo de ejecución implica agrupar cada microfrontend como un archivo JavaScript y permitir que el contenedor decida cuándo renderizarlo. La integración en tiempo de compilación utiliza el registro de NPM para convertir los componentes en paquetes que se pueden instalar como dependencias. Sin embargo, el uso de componentes de paquete requiere reconstruir toda la aplicación. Trabajar en un equipo autónomo puede llevar a errores en la aplicación contenedora, lo que dificulta la prueba de características específicas.

BFF evolucionó junto con el microfrontend. Sí, me has oído bien. No se abrevia como mejor amigo para siempre, pero lo es. En realidad, la abreviatura de BFF es backend para frontend, que actúa como el mejor amigo del microfrontend, así como del microservicio. Entonces, si observas detenidamente este diagrama, la comunicación entre el microfrontend y el microservicio no está conectada directamente. Ocurre a través de BFF. Aquí, BFF actúa como intermediario entre ellos y también utiliza las cargas o esfuerzos que un microfrontend debería hacer. Entonces, cualquier solicitud que provenga del microfrontend se pasa al servicio. Cualquier respuesta que dé el servicio se transpila de tal manera que el microfrontend pueda entenderla y mostrarla. Aquí se reduce al máximo el esfuerzo del microfrontend. Además, si observamos detenidamente este diagrama, no habrá comunicación entre los microfrontends aquí. Cada microfrontend está conectado directamente al contenedor, que se llama shell de la aplicación, y las decisiones importantes se toman solo en el contenedor. No hay comunicación entre los microfrontends aquí. Así es como funciona un microfrontend. Cuando hablamos de microfrontends, hay dos estrategias importantes que utilizamos. Estrategias de integración, cómo integramos los microfrontends en un solo contenedor. Podemos categorizarlo en dos tipos diferentes. Uno es la integración en tiempo de ejecución y el otro es la integración en tiempo de compilación. Cuando hablamos de la integración en tiempo de ejecución, cada microfrontend se agrupa y se convierte en un archivo JavaScript, y se vincula a la aplicación contenedora en una etiqueta de script. Y el contenedor tomará la decisión sobre en qué circunstancias se debe renderizar este paquete en particular en el navegador. Consideremos el escenario en el que el equipo A decide desarrollar un componente C, lo desarrollan y lo implementan en la ruta, el nombre de dominio seguido de /component.js, que es nuevamente un paquete. Entonces, cuando el usuario navega al dominio, es decir, el dominio del contenedor, la aplicación del contenedor carga el dominio, carga el componente C y luego lo muestra en la ruta específica. Nuevamente, el contenedor toma el control total. Esta configuración tiene sus propias desventajas, ya que el tiempo de configuración es demasiado largo y la implementación independiente es demasiado desafiante. Y pasando a la otra estrategia que tenemos, que es la integración en tiempo de compilación. Aquí, con esta estrategia, el registro de NPM se convirtió en nuestro salvador, donde podemos convertir nuestro componente que estamos desarrollando en un paquete y simplemente implementarlo en nuestro registro de NPM. Los equipos que deseen utilizar ese componente en particular, el otro equipo de microfrontend o cualquier otro equipo autónomo que desee utilizar ese componente en particular, simplemente pueden instalar ese componente como una dependencia en su aplicación y pueden usarlo. La desventaja de esta integración en tiempo de compilación es que, nuevamente, una vez que estás utilizando un componente de paquete como una dependencia, es necesario reconstruir todo el paquete, toda la aplicación. Por lo tanto, el tiempo de agrupación y el tiempo de reconstrucción serán demasiado largos. También hubo otras preocupaciones sobre nuestra estrategia de microfrontend, una de ellas es trabajar en un equipo autónomo. Mientras trabajábamos en un equipo autónomo, cada equipo se encarga de su propio microfrontend, ni siquiera se preocupa por los demás equipos. Pero aún así, podría haber una posibilidad de que se presente un error en la aplicación contenedora, lo que significa que solucionar un error en la aplicación contenedora será obviamente una tarea tediosa y difícil de ejecutar una experiencia completa. Si alguien quiere probar una parte específica de una función, debe reconstruir toda la aplicación una vez y luego probar la parte específica.

5. Multiplicando la Arquitectura y la Abstracción de Canales

Short description:

La depuración de problemas en aplicaciones de microfrontend más grandes puede ser desafiante. Las preocupaciones de estilo CSS se pueden abordar utilizando estrategias de CSS-in-JS o iframes, aunque los iframes tienen desventajas y se consideran una tecnología obsoleta. Para superar las limitaciones de los microfrontends, desarrollamos la arquitectura de multiplicación. Esta arquitectura permite que las aplicaciones se ejecuten en múltiples distribuciones con cambios mínimos en el código y proporciona un puente entre diferentes pilas tecnológicas. Los elementos principales de la arquitectura de multiplicación son los canales, sobres, vistas y editores.

característica más pequeña. Nuevamente, eso es muy difícil. Nuevamente, depurar un problema en una aplicación más grande de microfrontend, aunque sea un microfrontend múltiple, será difícil. Aparte de estos equipos autónomos, hay otras preocupaciones relacionadas con el estilo CSS. Si estás escribiendo algún CSS en un marco específico, en un microfrontend específico, eso puede ser anulado en otros microfrontends también. Eso puede afectar tu vista general de la aplicación. Y, además, para superar esto, en realidad puedes usar una estrategia de CSS en JS como los componentes de estilo o algo similar, algunas bibliotecas como esas. Y puedes usar iframes. Aunque, quiero decir, este iframe aislará completamente tu microfrontend del mundo exterior para que puedas, incluso si hay un estilo CSS que se está anulando, no afectará a tu componente. Así es como se puede crear un iframe aquí. Entonces, puedes incrustar tu iframe en tu etiqueta de script y la fuente para tu iframe se puede pasar de esta manera. Entonces, también hay algunas desventajas con los iframes. Entonces, estos iframes no son algo nuevo, en realidad. Son una tecnología antigua. Creo firmemente que en este punto, en esta evolución de las tecnologías, nadie seguirá prefiriendo usar un iframe para su aplicación. Entonces, aunque los microfrontends están aislados, debería haber al menos algún tipo de paso de datos entre los microfrontends que se debe habilitar. Usando iframes, este paso de datos es nuevamente un problema. Para superar esto, hasta ahora hemos visto todas las preocupaciones asociadas con los microfrontends.

Entonces, para superar todas estas cosas, decidimos desarrollar un marco para abordar todos estos problemas y también para abordar los requisitos. Entonces, comenzamos a pensar en una arquitectura. Entonces, los requisitos eran que queríamos que nuestra aplicación o la herramienta se ejecutara en múltiples distribuciones. Como mencioné, las distribuciones eran VS Code, GitHub, navegador y la aplicación web. Y con cambios mínimos en el código, mis componentes deben ejecutarse en todas las demás distribuciones. Y también, debería haber un puente entre la tecnología o las pilas tecnológicas, lo que elija. En caso de que quiera cambiar mi pila tecnológica en un futuro cercano, eso aún debería ser posible con un esfuerzo mínimo. Entonces, para abordar todas estas cosas, introdujimos la arquitectura de multiplicación. Entonces, antes de adentrarnos en la arquitectura de multiplicación, ¿qué queremos decir con la arquitectura de software? Nuevamente, hay una cita de Ralph Johnson, la arquitectura se trata de las cosas importantes, sea lo que sea, ¿verdad? Te explicaré lo que significa exactamente. Entonces, la idea principal detrás de esta arquitectura de multiplicación es la abstracción. Queríamos que nuestros componentes de React se abstrajeran y se envolvieran, y ese envoltorio debería incluirse en la plataforma donde queremos ejecutar los componentes específicos. Entonces, los conceptos principales o los elementos principales de la arquitectura de multiplicación son estos. El primero es el canal, sobre, vista y editor. El canal, lo que quiero decir aquí es

6. Arquitectura de Multiplicación y Comunicación de Canales

Short description:

La vista son los componentes de React, y el sobre actúa como mediador entre el canal y la vista. El editor está envuelto dentro del sobre, que luego está envuelto dentro del canal. Las ventajas del sobre incluyen el aislamiento del contexto, la implementación de equipos autónomos, los ciclos de lanzamiento independientes y la seguridad de tipos completa. La arquitectura de multiplicación se puede ver en la práctica con los ejemplos de código proporcionados, como el paquete TodoList, que incluye las carpetas API, incrustada y sobre. Los archivos API, canal y sobre son responsables de la comunicación entre el canal y la API.

En las plataformas que hemos estado discutiendo hasta ahora, ya sea VS Code, GitHub o la extensión del navegador o la aplicación web. La vista son obviamente los componentes de React que tenemos, y el sobre, que actúa entre el canal y la vista o actúa como mediador entre el canal y la vista y pasa mensajes entre ellos. Y el editor es nuevamente el dm y el editor que tenemos en nuestro ejemplo anterior. Entonces, queríamos implementar nuestra herramienta en el canal en línea como este. Aquí puedes ver el canal en línea. Entonces, el editor está envuelto dentro del sobre, y el sobre está envuelto dentro del canal. Queríamos que nuestra herramienta se ejecutara en una extensión del navegador como esta, en una extensión de GitHub como esta y en una extensión de VSCode como esta. Aquí viene de nuevo. Entonces, este canal, quiero decir, nuevamente, si ves aquí, una implementación simple de lo que estábamos haciendo con la arquitectura de multiplicación es, nuevamente, el canal está envuelto, quiero decir, el iframe está envuelto dentro de un canal, y este iframe contiene el editor, quiero decir, el editor, los componentes, lo que sea, quiero decir, mi editor contiene los componentes de React, y el sobre actúa como mediador entre el canal y los componentes de React. Entonces, las ventajas del sobre son el aislamiento del contexto. Está totalmente aislado, cada microfrontend está aislado del otro, pero aún así es posible el paso de datos entre ellos. Implementación de equipos autónomos. Cada equipo podría trabajar individualmente en su microfrontend específico. Ciclo de lanzamiento independiente, pueden tener ciclos de lanzamiento independientes y también pueden tener canalizaciones de CI/CD independientes. La principal ventaja de esta arquitectura de multiplicación es que es completamente segura en cuanto a tipos. Estamos usando TypeScript aquí, por lo que es totalmente segura en cuanto a tipos. Veamos la arquitectura de multiplicación en la práctica. Para eso, te llevaré a través de la base de código aquí. Compartiré contigo la URL de esta base de código donde tenemos este conjunto de ejemplos que implementamos para la arquitectura de multiplicación. Todos los paquetes que ves en esta biblioteca están basados en la arquitectura de multiplicación. Puedes tomar cualquier ejemplo de ella, pero para un ejemplo más sencillo, tal vez solo tomemos el caso de uso regular o el ejemplo regular que construimos para cualquier marco que es TodoList. Aquí puedes ver un paquete TodoList que contiene tres estructuras de carpetas. Una es para API, incrustada y sobre. API solo contiene los métodos requeridos para el mundo externo. Mundo externo aquí me refiero a los canales. Hay un archivo llamado API de canal. Este contiene un conjunto de métodos que el canal expone y que el sobre consume. Otro archivo llamado API de sobre que contiene un método que es expuesto por el sobre y consumido por el canal. Estos 3 archivos son responsables de la comunicación entre el canal y la API. Cualquier método que quieras implementar...

7. Lista incrustada y módulos federados

Short description:

Mostraré cómo la lista incrustada sirve como punto de entrada para los componentes de React. La vista del sobre de la lista de tareas de TS contiene el código de React, HTML y CSS. Esta incrustación actúa como punto de entrada para tus componentes de React. Logramos que el mismo conjunto de código funcione en dos plataformas diferentes. La duplicación de la carga de bibliotecas es un problema común en la integración en tiempo de compilación y en tiempo de ejecución. Los módulos federados, introducidos por Webpack, permiten compartir bibliotecas y dependencias entre micro frontends y cargarlos cuando sea necesario.

Podemos abstraer esto aquí y definir este método en tu canal. Mostraré cómo se define. Hay otra carpeta llamada incrustada. Esta lista incrustada se considera como el punto de entrada para los componentes de React. Aquí puedes ver la línea que llama a la lista de tareas incrustada. Esto proviene de la carpeta de sobre, que es un componente TSX que expone la vista. Aquí está la vista. La vista del sobre de la lista de tareas de TS contiene el código de React, HTML y CSS, todas esas cosas aquí. Esto se llama dentro del sobre y el sobre se llama dentro de la incrustación. Esta incrustación actúa como punto de entrada para tus componentes de React. Este es el flujo para la vista de la lista de tareas y es un micro frontend, por lo que puedes usar este micro frontend en diferentes plataformas. Quería ejecutar esta aplicación en VS Code y también en la aplicación web, así que creamos una extensión separada de VS Code con todos los requisitos para una extensión. Porque VS Code tiene su propia extensión y conjunto de reglas que deben seguirse y que deben estar activas y, en primer lugar, la extensión debe estar activada, así que antes de implementar la extensión de VS Code, debes tener en cuenta todas estas cosas. Aquí se realizan las suscripciones y luego se renderiza el componente. Si ves aquí, hay un index.ts que iniciará el componente, quiero decir, el sobre que tenemos y que exportamos desde esta incrustación del canal. Aquí, esta extensión de VS Code es un canal, nuevamente, en el caso de una aplicación web, tenemos nuevamente una carpeta de origen que tiene una página de lista de tareas. Ahora, si bajas, verás que se llama a la lista de tareas incrustada aquí. Esta lista de tareas incrustada se importa desde la vista de la lista de tareas, que es otro microfrontend. Así que aquí logramos que el mismo conjunto de código funcione en dos plataformas diferentes. Volviendo a mis diapositivas. Incluso después de implementar la vista del canal del sobre y la arquitectura de multiplicación, todavía teníamos algo que faltaba en nuestro diseño de arquitectura. Teníamos un problema con los problemas de integración en tiempo de compilación y en tiempo de ejecución. Los problemas comunes que enfrentamos en ambas estrategias son la duplicación de la carga de bibliotecas. Considera un escenario en el que tenemos una aplicación que tiene tres micro frontends y cada micro frontend tiene React como una dependencia. Con esto, se crearon tres instancias de React, lo cual definitivamente no es algo bueno. Considera si tienes demasiadas dependencias y cada una de las dependencias crea su propia instancia para cada micro frontend, el tamaño de tu aplicación será demasiado grande. Para reducir eso y superar este problema, los módulos federados vinieron a rescatarnos. Es posible que hayas escuchado este término, módulos federados. Fue introducido por Webpack en su quinta versión. Permite compartir bibliotecas y dependencias entre los micro frontends.

8. Configuración de Webpack y Arquitectura de Multiplicación

Short description:

En lugar de cargar el micro frontend de una vez, hicimos la configuración de Webpack para cargar micro frontends específicos según la ruta. Las bibliotecas compartidas y las dependencias entre micro frontends reducen el tamaño del paquete. Se utilizaron características de React como importaciones diferidas, carga diferida y suspense para cargar micro frontends cuando sea necesario. Utilizando estrategias de micro frontend, BFF, módulos federados y arquitectura de multiplicación, desplegamos nuestra aplicación en múltiples distribuciones con un código mínimo. La arquitectura de multiplicación eliminó los iframes y permitió una fácil separación o acoplamiento de la aplicación monolítica.

En lugar de simplemente cargar los componentes, solo cargamos el micro frontend de una vez en tu navegador. Veamos cómo se hace. Así es como hicimos la configuración de Webpack en la raíz del archivo de configuración. Importamos el módulo de federación, que tiene remotos y cada ruta remota puede estar vinculada a su propio micro frontend. Solo se cargará el micro frontend correspondiente cuando se acceda a una ruta de marketing. Hasta entonces, no se cargará el micro frontend de marketing. Simplemente se mantendrá allí. De manera similar, sucede con la autenticación y el panel de control. Si observas aquí, las bibliotecas y las dependencias se comparten entre estos tres micro frontends, por lo que no se crean instancias individualmente y el tamaño del paquete se reducirá. Al utilizar este micro frontend en nuestros componentes de React, utilizamos otras características de React como importaciones diferidas, carga diferida y suspense para cargar el micro frontend cuando sea necesario. Aquí, si observas, las importaciones se cargan de forma diferida y aquí, si observas, los componentes se renderizan solo si se accede a una ruta específica. Después de hacer todas estas cosas, es decir, utilizando algunas partes de las estrategias de micro frontend, como BFF, módulos federados y, además, utilizando nuestra arquitectura de multiplicación, logramos nuestro objetivo de desplegar nuestra aplicación en múltiples distribuciones con un conjunto mínimo de código. También desarrollamos un puente donde la etiqueta de texto podría ser reemplazada en el futuro con un cambio mínimo de código. Estos fueron los logros que pudimos obtener de la arquitectura de multiplicación. La primera cosa es la arquitectura de microservicios. Es decir, pudimos implementar la arquitectura de microservicios en el mundo del frontend. Finalmente pudimos aprovechar la integración en tiempo de ejecución. Cada equipo pudo construir o desplegar sus propios módulos. No hay duplicación de la biblioteca al cargar. Y pudimos desplegar múltiples partes de nuestra aplicación en diferentes servidores sin iframes. Esa es la principal ventaja que tenemos. Con esta arquitectura de multiplicación, eliminamos por completo los iframes. Los reemplazamos con la etiqueta div, para que no esté totalmente aislado. El micro frontend termina como un componente de React. En caso de que desees romper tu aplicación monolítica, puedes hacerlo fácilmente. En caso de que no desees romperla y quieras acoplarla nuevamente, puedes hacerlo fácilmente con un esfuerzo mínimo. Con eso, hemos llegado a una conclusión. Si tienes alguna pregunta, por favor, pregúntala.

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.
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.
React Advanced Conference 2022React Advanced Conference 2022
29 min
Understanding React’s Fiber Architecture
Top Content
We've heard a lot about React's Fiber Architecture, but it feels like few of us understand it in depth (or have the time to). In this talk, Tejas will go over his best attempt at understanding Fiber (reviewed by other experts), and present it in an 'explain-like-I'm-five years old' way.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Finland 2021React Finland 2021
36 min
The Eternal Sunshine of the Zero Build Pipeline
For many years, we have migrated all our devtools to Node.js for the sake of simplicity: a common language (JS/TS), a large ecosystem (NPM), and a powerful engine. In the meantime, we moved a lot of computation tasks to the client-side thanks to PWA and JavaScript Hegemony.
So we made Webapps for years, developing with awesome reactive frameworks and bundling a lot of dependencies. We progressively moved from our simplicity to complex apps toolchains. We've become the new Java-like ecosystem. It sucks.
It's 2021, we've got a lot of new technologies to sustain our Users eXperience. It's time to have a break and rethink our tools rather than going faster and faster in the same direction. It's time to redesign the Developer eXperience. It's time for a bundle-free dev environment. It's time to embrace a new frontend building philosophy, still with our lovely JavaScript.
Introducing Snowpack, Vite, Astro, and other Bare Modules tools concepts!
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.

Workshops on related topic

DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Workshop
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
JSNation Live 2021JSNation Live 2021
113 min
Micro-Frontends with Module Federation and Angular
Workshop
Ever more companies are choosing Micro-Frontends. However, they are anything but easy to implement. Fortunately, Module Federation introduced with webpack 5 has initiated a crucial change of direction.
In this interactive workshop, you will learn from Manfred Steyer -- Angular GDE and Trusted Collaborator in the Angular team -- how to plan and implement Micro-Frontend architectures with Angular and the brand new webpack Module Federation. We talk about sharing libraries and advanced concepts like dealing with version mismatches, dynamic Module Federation, and integration into monorepos.
After the individual exercises, you will have a case study you can use as a template for your projects. This workshop helps you evaluate the individual options for your projects.
Prerequisites:You should have some experience with Angular.