Construyendo un Mejor Marco de Micro-Frontend que Permite la Libertad de Plataforma

Rate this content
Bookmark
Slides

Una experiencia moderna de herramientas generalmente implica un viaje de usuario en varios medios, incluyendo Web, VS Code, GitHub, etc. Escribir código y componentes personalizados para cada plataforma no es el enfoque más eficiente, lo que lleva a la duplicación de código y, lo más importante, el riesgo de una falta de una experiencia cohesiva.
La Arquitectura Multiplicadora es un conjunto de patrones, técnicas y bibliotecas que, utilizando micro frontends y algunos servicios de backend innovadores, permiten la reutilización del componente de herramientas en diferentes medios de distribución
Ven a esta charla para aprender cómo somos capaces de permitir a varios equipos de herramientas en Red Hat entregar la mejor experiencia nativa de componentes de UI (s y Vistas) en VS Code, Web, y Desktop, e integrarlos directamente en GitHub (Extensión de Chrome) con cambios mínimos en su base de código.

28 min
12 Dec, 2023

AI Generated Video Summary

Esta charla discute los desafíos de escalar y mantener aplicaciones y cómo las decisiones de arquitectura pueden impactarlas. Introduce el concepto de Microfrontend y sus ventajas de escalado más fácil, identificación de problemas y diversificación de pilas de tecnología. Se explica la implementación de Microfrontend en Red Hat, incluyendo el uso de un nuevo marco, estrategias de comunicación y la necesidad de escalabilidad y mantenimiento en aplicaciones grandes. La charla también cubre el marco de arquitectura multiplicadora de micro frontend y sus componentes centrales. Se muestra la implementación de Microfrontend en VS Code y ejemplos de combinación de diferentes marcos en una sola aplicación. Se aborda el problema de la duplicación de la carga de la biblioteca utilizando módulos federados en webpack.

1. Introducción al Micro Front-end

Short description:

Hola a todos, bienvenidos a mi charla sobre cómo construir una mejor aplicación de micro front-end. Soy Sarvana Balaji Srinivasan, un ingeniero de software senior en Red Hat con experiencia en marcos de JavaScript como React, Angular y Node.js. Hoy quiero discutir los desafíos de escalar y mantener aplicaciones, y cómo las decisiones de arquitectura pueden impactarlas. Sumérgete en la historia de Red Hat, donde mejoramos el producto Jbpm con las últimas tecnologías y tecnologías en la nube.

Hola a todos, espero que estén pasando un buen rato escuchando algunas de las charlas realmente interesantes en el evento remoto de React Day Berlin. Definitivamente, mi charla mantendrá este impulso y entregará algunas cosas interesantes sobre micro front-end. Con esa nota, les doy la bienvenida a mi charla, Construir una mejor aplicación de micro front-end que ofrece libertad de plataforma.

Soy Sarvana Balaji Srinivasan. Trabajo como ingeniero de software senior en Red Hat, con el rol de desarrollador full stack. Principalmente hago tecnologías de JavaScript. He estado contribuyendo a la plataforma AI de Red Hat OpenShift. Trabajo en cosas de UI así como en algunas cosas de computación de borde. Tengo experiencia trabajando en varios marcos de JavaScript como React, Angular, Node.js, etc. Entonces sí, eso es sobre mí.

Estás viendo la conferencia de React, ¿verdad? Entonces hablemos de JavaScript y React. Han pasado 28 años desde que se introdujo JavaScript. Ya ha pasado su marca de años de jubileo de plata de 25 años. Y el crecimiento de JavaScript ha sido tremendo a lo largo de los años después de la introducción de marcos emocionantes. Incluso los principales marcos construidos en JavaScript han estado aquí durante bastante tiempo. React ha estado aquí durante 10 años. Angular y Node.js han estado aquí durante casi 14 años. Vue.js ha estado aquí durante casi 9 años y la lista continúa. Eso significa que tenemos aplicaciones que son un poco antiguas ahora. Ahora, quiero decir que las aplicaciones han sido desarrolladas y mantenidas durante mucho tiempo. Eventualmente, las aplicaciones siguen creciendo, creciendo y creciendo exponencialmente. Cuando las aplicaciones están creciendo mucho, son realmente difíciles de escalar y mantener. Empezarás a recibir quejas de tus clientes sobre varias cosas y problemas asociados con ello. Por supuesto, no es solo por JavaScript o el marco de JavaScript, podría haber varias razones asociadas con ello que es un tema aparte a discutir. Pero una razón podría ser la decisión de la organización sobre cómo quieren construir su aplicación, la arquitectura. En Red Hat tuvimos una situación similar.

Ahora esto me lleva a la siguiente diapositiva, la historia de Red Hat. Teníamos un producto llamado Jbpm que es un producto de automatización de negocios que se considera como uno de los pilares principales de Red Hat. Era un producto heredado. En algún momento, decidimos mejorar el producto y acomodar algunas de las últimas tecnologías, haciéndolo disponible como un servicio con tecnologías en la nube.

2. Introducción al Microfrontend

Short description:

Esta parte discute la experiencia de descomponer un gran bloque de aplicaciones web monolíticas en Red Hat. Introduce el concepto de Microfrontend, enfatizando su objetivo de desacoplar y descomponer una aplicación monolítica en piezas más pequeñas. Las ventajas de Microfrontend incluyen una escalabilidad más fácil, identificación de problemas y diversificación de pilas de tecnología.

Fue entonces cuando nos encontramos en una situación para descomponer un gran bloque de aplicaciones web monolíticas. Ya teníamos Microsoft Visual en ese momento en el back end, pero nuestro front end era un gran bloque de aplicaciones monolíticas que queríamos descomponer. Esta charla es sobre compartir la experiencia que tuvimos en Red Hat al construir la aplicación monolítica y cómo nuestro nuevo marco, la multiplicación de architecture, permitió ejecutar los web components en la plataforma que teníamos como objetivo.

Antes de entrar en Microfrontend, hablemos de los patrones arquitectónicos disponibles. Los paisajes arquitectónicos están cambiando mucho en los últimos años, comenzando con la architecture evolutiva, construyendo software que está diseñado para evolucionar con el tiempo a medida que cambian las prioridades comerciales, cambian las demandas de los clientes y surgen nuevas tecnologías. Luego tenemos los microservices, que estructuran una aplicación como una colección de servicios independientes. Luego tenemos la palabra de moda, que es serverless en este punto, que incorpora backend como una función. Finalmente tenemos Microfrontend aquí. Así que Microfrontend no es algo nuevo. Ya ha estado aquí durante bastante tiempo. Antes de entrar en Microfrontend, me gustaría presentar una cita de un reconocido desarrollador de software llamado Cam Jackson. Según él, un estilo arquitectónico donde las aplicaciones de frontend independientes se componen en un todo mayor. Discutiremos lo que quiso decir en esta cita en detalle en las próximas diapositivas. Pero entraremos en qué es Microfrontend. Se lo pasaré a ustedes. No quiero aburrirlos con la definición de Microfrontend. Estoy seguro de que ya habrán oído suficiente sobre ello en otras charlas y presentaciones. Así que si todavía quieren saber la definición de Microfrontend, les recomendaría encarecidamente que revisen esas charlas para entender la definición. Pero me gustaría saltar directamente al principal objetivo de Microfrontend, que es el desacoplamiento. Así que el principal lema de Microfrontend es romper tu gran bloque monolítico de aplicación en piezas más pequeñas y hacer la vida del desarrollador más fácil. Tiene muchas ventajas. Algunas de ellas son que la escalabilidad y la identificación de problemas serán más fáciles. Y hay un dicho que dice que no tienes que poner todos tus huevos en una sola canasta, ¿verdad? Así que como se muestra en esta imagen, no tienes que poner todo en una sola canasta. Será difícil de manejar. Tiendes a romperlo. Así que esto se aplica a tu tecnología también. No tienes que poner todo en tu única canasta, así que puedes diversificar tu aplicación. Así que la diversificación no es solo para tu riqueza o dinero. Siempre puedes diversificar tus pilas de tecnología también, haciendo que tu aplicación sea fácil de acceder y mantener. Así que mientras discutimos sobre microfinanzas, las microfinanzas no son la única solución que tenemos en este punto para mantener tu aplicación.

3. Resumen de las opciones de aplicación

Short description:

Puede elegir entre aplicaciones basadas en monolíticos, enfoques amigables con micro, aplicaciones monolíticas modulares, aplicaciones integradas y micro-frontend. Nuestro objetivo era construir una mejor aplicación micro-frontend que ofrezca libertad de plataforma. Nuestras plataformas objetivo incluyen VSCode, Browser Extension, GitHub y WebApp. La tecnología web se ha convertido en la solución preferida en el desarrollo de software debido a su sólida base, patentes, técnicas y estándares. La disponibilidad de navegadores en todas partes nos motivó a dirigirnos a estas plataformas.

También tenemos otras cosas de las que hablar. Esta diapositiva le dará una visión general al respecto. Todavía puede optar por aplicaciones basadas en monolíticos. Para ser precisos aquí, la elección de cualquier opción de esta lista se basa en la decisión de su organización. Todavía puede optar por enfoques amigables con micro o cualquier otro enfoque que hayamos mencionado aquí. Todavía puede optar por una aplicación basada en monolíticos considerando que tiene una aplicación más sencilla donde tiene su aplicación front-end y tiene una aplicación back-end. Se comunican entre sí para producir algunos resultados. Si su aplicación es más pequeña y fácil de mantener, todavía puede optar por una aplicación basada en monolíticos.

O puede optar por una aplicación monolítica modular, que es similar a un monolito y ofrece modules que pueden ser fácilmente reemplazados. Es una especie de reutilización. También puede optar por una aplicación integrada en la que tiene aplicaciones independientes y se comunican o integran en la composición incorporada. Y finalmente tenemos micro-frontend. Haré una pausa aquí y volveré a mi título, construir una mejor aplicación micro-frontend que ofrezca libertad de plataforma. Me gustaría enfatizar lo que quiero decir con el término plataforma aquí. Como mencioné, trabajo para el equipo donde construimos herramientas para productos de automation empresarial o especificaciones de flujos de trabajo serverless, etc. Que son utilizados por los desarrolladores y las comunidades de todo el mundo. Así que queríamos que nuestros web components se ejecutaran en plataformas que nuestros desarrolladores y comunidades utilizan con más frecuencia. Así que esas son VSCode, Browser Extension, GitHub y finalmente WebApp. Así que estas son las plataformas que estábamos apuntando. ¿Por qué elegimos estas plataformas? Estamos en un mundo donde la tecnología web tiene un dominio completo en el desarrollo de software. Se considera la solución preferida para cualquiera que quiera construir una aplicación para su caso de uso. Esto se debe a que la tecnología web tiene una base más sólida, patentes más fuertes, técnicas más fuertes, standards más fuertes. Ha alcanzado un ecosystem que ha crecido rápidamente a lo largo de los años. Después de la introducción de TypeScript, personas como yo que comenzaron una career como desarrollador de Java comenzaron a gustarles la tecnología web después de trabajar en TypeScript. Personalmente siento que mi código es totalmente seguro en términos de tipos, mientras trabajo con TypeScript. Otra razón para elegir esas plataformas objetivo es que ahora puedes encontrar un navegador en cualquier lugar. Un navegador no es solo una herramienta para acceder a su internet en el mundo actual. Se ha convertido en algo más que eso. Puede encontrar un navegador en las plataformas que mencioné, como VS Code como una extensión, extensión de VS Code o extensión de GitHub, extensión de navegador o dispositivos móviles. Así que queríamos dirigirnos a esas plataformas debido a la disponibilidad de navegadores en todas partes.

4. Implementación y Características de Microfrontend

Short description:

Esta parte discute la experiencia de implementar un nuevo marco de trabajo para Microfrontend en Red Hat para ejecutar componentes web en plataformas de herramientas de desarrollo como VS Code, extensiones de navegador y aplicaciones web. Proporciona un ejemplo de desglose de una herramienta llamada editor BPMN en microfrontends más pequeños, destacando la necesidad de escalabilidad y mantenimiento en aplicaciones grandes. Se explica el uso de BFF (Backend para Frontend) como canal de comunicación entre microfrontends y el backend, junto con los dos tipos de estrategias de integración: integración en tiempo de ejecución e integración en tiempo de compilación.

Y queríamos hacer que nuestras empresas web se ejecutaran en esos lugares para que incluso los desarrolladores puedan acceder a esas aplicaciones web más fácilmente. Así que ahora debes haber entendido lo que quiero decir con el término plataforma en mi título. Esta charla completa es acerca de compartir la experiencia que tuvimos en Red Hat al implementar un nuevo marco de trabajo para Microfrontend para ejecutar nuestros web components en la plataforma de herramientas de desarrollo. Así es como queríamos ejecutar nuestros web components en nuestras plataformas objetivo como VS Code, extensión de navegador o aplicación web, etc.

Aquí hay un pequeño ejemplo de cómo queríamos desglosar una de nuestras herramientas llamada editor BPMN. El editor BPMN es una herramienta para design el proceso de negocio y representarlo de manera gráfica. Puedes pensar por qué elegimos implementar Microfrontend para una interfaz de usuario tan pequeña mirando esta captura de pantalla. Por supuesto, es solo una pequeña parte de nuestra aplicación más grande. Nuestra aplicación actual tiene casi 600 a 700 componentes, lo cual es realmente enorme. Volviendo a la captura de pantalla, si miras de cerca esta captura de pantalla, la interfaz de usuario está desglosada en microfrontends más pequeños. El encabezado está separado como un microfrontend y hecho por un equipo separado. El explorador a la izquierda podría ser hecho como un microfrontend separado y el editor real en el medio podría ser hecho por un equipo separado como un microfrontend separado. Así que de nuevo, esta es una pequeña interfaz de usuario. Esta captura de pantalla es una pequeña captura de pantalla pero solo imagina una aplicación más grande como Amazon, Twitter, Instagram o algo así que va a tener un gran número de componentes. De nuevo, no puedes mantener una aplicación tan grande como una aplicación basada en monolíticos. Definitivamente tienes que desglosarla en aplicaciones microfrontend más pequeñas para que pueda ser escalada y mantenida fácilmente.

Pasemos a las características de microfrontend. Así que uno de los patterns principales que propone microfrontend es el uso de BFF. ¡Sí! ¡Lo escuchaste bien! En realidad no se abrevia como mejor amigo para siempre sino que es el mejor amigo para el microfrontend. De nuevo, si miras de cerca, mira este diagrama. BFF se queda en el medio entre el microfrontend y el backend y actúa como medio de comunicación entre ellos. Cualquier solicitud que provenga del microfrontend es modificada por el BFF en el medio y se pasa al backend de tal manera que el backend pueda entenderla. Hace lo mismo al manejar la respuesta que viene del backend y la pasa a través del frontend. Entonces, luego vienen los tipos de integración. Así que esto se considera lo más importante a considerar al implementar el microfrontend. Así que hay dos tipos de estrategias de integración disponibles. Una es la integración runtime y la otra es la integración en tiempo de compilación. Profundizaremos en estas dos cosas. Primero, la integración Runtime también conocida como integración del lado del cliente. Imagina que el Equipo A decide desarrollar una nueva versión del Componente C, lo despliegan y publican como la URL mencionada aquí, mydomain.com.c.js.

5. Arquitectura y Estilización de Microfrontend

Short description:

La aplicación contenedor tiene control total sobre la aplicación y los componentos. El Equipo A puede desplegar el Componente C de forma independiente, con el contenedor decidiendo qué versión usar. El enfoque de integración en tiempo de compilación permite una fácil configuración y mantenimiento, pero requiere el despliegue del contenedor. Las preocupaciones de estilo en Micro-Frontends se pueden abordar utilizando bibliotecas de CSS y JS o iframes. Estas soluciones tienen sus pros y contras. Se necesitaba la nueva arquitectura para desplegar los mismos componentes en múltiples plataformas con cambios mínimos de código.

Entonces, el usuario navega a la URL mydomain.com, la aplicación contenedor es algo que tiene el control total aquí. Carga la aplicación y carga los componentes. El nuevo Componente C es obtenido por el contenedor. Así que aquí, como mencioné, el contenedor toma el control total sobre esta aplicación. La ventaja de este enfoque es que el Equipo A puede desplegar el Componente C de forma independiente y puede desplegar diferentes versiones de él, el contenedor decide cuál usar. La desventaja es que la configuración y la puesta en marcha de este enfoque es un poco complicada.

Luego viene el siguiente enfoque, la integración en tiempo de compilación, también conocida como integración en tiempo de compilación. Aquí el Equipo A decide desarrollar una nueva versión del Componente C. Lo ponen en un registro público como un paquete npm y el Equipo B que quiere usar esa versión del Componente C, instala el componente o simplemente aumenta una versión de él y lo usan. La ventaja de este enfoque es que es fácil de configurar y mantener, pero el contenedor tiene que ser desplegado cada vez, eso se considera como una desventaja de este enfoque.

Hay otras preocupaciones asociadas con el estilo al usar los Micro-Frontends. Podría ser como si imaginas múltiples aplicaciones Micro-Frontend y podría haber ciertas clases que se repiten, clases CSS que se repiten a través de los Micro-Frontends. Las propiedades CSS de una clase podrían ser sobrescritas en otros Micro-Frontends y que podrían resultar en la ruptura de tu interfaz de usuario. Hay ciertas soluciones para superar este problema. Una solución famosa es usar bibliotecas de CSS y JS. Hay muchas bibliotecas disponibles. Una de las más famosas es Tiled Components donde puedes escribir código CSS directamente en los archivos Java también. Otra solución es un enfoque antiguo usando iframes. Resuelve el problema de aislar tu micro frontend del mundo exterior. Pero, de nuevo se considera un enfoque antiguo. Aquí hay un ejemplo simple de cómo puedes usar un iframe para envolver tu micro frontend y simplemente renderizar en la aplicación contenedor. Si miras de cerca este código aquí en la línea 18, iframe.src contiene el código fuente de otro micro frontend así es como un micro frontend será renderizado en un iframe y ese iframe será renderizado en la aplicación contenedor. Así que hay ciertos pros y contras asociados con los iframes que he listado aquí. Los pros podrían ser de nuevo que puedes aislar tu micro frontend del mundo exterior. Pero por otro lado hay una lista de contras como que hace que tu aplicación parezca un poco antigua y es menos flexible.

Entonces, ¿por qué necesitábamos una nueva arquitectura? Teníamos estos requisitos, queríamos tener múltiples distribuciones para desplegar el mismo conjunto de componentes en varias plataformas con cambios mínimos de código para abrazar diferentes generaciones de pilas tecnológicas. Estos eran nuestros objetivos finales. Ahora entenderemos qué es la arquitectura de software antes de entrar en la arquitectura de multiplicación. Según Ralph Johnson, la arquitectura es acerca de lo importante, sea lo que sea. Lo importante de una aplicación debe ser considerado como prioridad.

6. Introducción a la Arquitectura de Multiplicación

Short description:

El marco de arquitectura de multiplicación de micro frontend introduce los componentes principales: canal, sobre, vista y editor. El canal representa el entorno de alojamiento, como VS Code, extensión de GitHub o extensión de navegador. El sobre permite una comunicación transparente entre la vista y el canal. La vista consta de un conjunto portátil de widgets, mientras que el editor central, incluyendo los editores BPMN y DMN, puede funcionar en diferentes plataformas. El sobre actúa como una capa de abstracción, facilitando la comunicación entre el canal y la vista. El sobre y la vista están envueltos dentro de un div, eliminando la necesidad de iframes y proporcionando una interfaz de usuario más realista. El componente sobre ofrece aislamiento de contexto, permitiendo equipos autónomos y ciclos independientes, al tiempo que permite la comunicación segura entre los micro frontends.

Ahora vamos a hacer una breve introducción a la multiplicación de la architecture, que es un marco de micro frontend. La idea principal de la arquitectura de multiplicación es tener abstracción. Estos son los componentes principales de la arquitectura de multiplicación. El canal, el sobre, la vista y el editor. El canal es el nivel superior de abstracción que representa el entorno de alojamiento. En nuestro caso podría ser VS Code, la extensión de GitHub o la extensión del navegador. Así que si estás utilizando esta arquitectura de multiplicación puedes tener tu plataforma o tu entorno como el canal.

Y luego tenemos el sobre que permite una comunicación transparente entre los componentes. Aquí los componentes, a lo que me refiero es a la vista y al canal. Así que permite la comunicación entre la vista y el canal. Luego la vista es un conjunto portátil de widgets. Y finalmente tenemos el editor central. El verdadero editor BPMN y DMN que queríamos hacer funcionar en diferentes plataformas. Así que queríamos tener nuestro editor funcionando en el canal en línea, como este. Vemos aquí que la línea amarilla marca como el canal y luego tenemos el sobre dentro de él, y luego tenemos el editor real dentro de él. Así es como funciona la capa de abstracción de esta arquitectura de multiplicación. Y luego queríamos que nuestro editor funcionara en el canal de escritorio como este. La extensión de GitHub actúa así, y la extensión de VS Code así. Así que este diagrama explica cómo el sobre permite la comunicación entre el canal y la vista. Así que actúa en medio. Y luego el sobre y la vista están envueltos dentro de un div. Si miras de cerca este diagrama aquí, no se utilizan iframes. Así que nos hemos deshecho del uso de iframe. Y luego hemos usado div, para que nuestra interfaz de usuario se vea más, quiero decir, más realista, ¿verdad? Y finalmente, tenemos el canal que envuelve todos estos componentes juntos dentro de él.

Así que el sobre se considera como el componente más importante de esta arquitectura de multiplicación. Así que necesitamos discutir un poco más sobre él. Así que lo que mi sobre ofrece es que te proporciona aislamiento de contexto. Hace que tu equipo trabaje como un tono. Quiero decir, como quiero decir, puedes tener un equipo autónomo en tus proyectos, y puedes tener ciclos independientes. Permite la comunicación segura entre los micro frontends.

7. Implementación de Microfrontend en VS Code

Short description:

Vamos a explorar la implementación de la arquitectura de micro frontend en la práctica utilizando VS Code. Recorreremos un repositorio que contiene ejemplos como Todo List y Ping Pong, que son ejemplos clásicos de React. El repositorio también incluye una carpeta webapp que sirve como la aplicación contenedora para los canales individuales. Nos centraremos en la vista de Todo List, que es una aplicación JAK y utiliza un sobre para la comunicación con el canal. El canal en sí es una extensión de TypeScript que inicia la vista. Además, examinaremos la vista de ping-pong, que ofrece dos opciones para la representación: iframe y div. Este enfoque elimina la necesidad de iframes.

Entonces, veamos micro amigo y architecture en la práctica. Vamos a entrar en VS Code. Compartiré la URL del repositorio. Habrá una diapositiva al final donde podrás acceder a eso. Es solo un código de fuente abierta. Puedes acceder libremente a ese código y ver cómo se implementa esta multiplicación architecture y cómo se utilizan las estrategias de micro amigo en él. Así que simplemente te guiaré a través de este repositorio y te mostraré cómo se han creado las carpetas, cómo se ha configurado el proyecto para que te sea fácil cuando lo intentes por tu cuenta. Hay una carpeta llamada ejemplos en este repositorio, que contiene algunos ejemplos clásicos que ya habrías probado en algunos de tus POCs anteriores como Todo List, Ping Pong. Estos son los ejemplos que cualquiera probará cuando aprenda React por primera vez, ¿verdad? Así que sí, de nuevo, esos ejemplos se construyen aquí.

Así que hay una carpeta llamada webapp, que es la aplicación contenedora, que va a contener todos los canales o aplicaciones individuales dentro de ella, y se ejecuta como una única aplicación web. Así que voy a ejecutar esta webapp y te mostraré cómo se ve en el navegador. Pero antes de eso, vamos a revisar esta carpeta, y ver cómo esta multiplicación real architecture y cómo se crean las carpetas, y cómo se hacen las configuraciones. Empezaremos con este canal aquí. Esta vista de Todo List, la extensión de VS Code es un canal. Y esta vista de Todo List es la vista, la vista real. Así que si recuerdas los componentes, los cuatro componentes principales de la multiplicación architecture que discutimos en nuestra diapositiva anterior, el canal, el sobre, la vista, y el editor, ¿verdad? Así que aquí, esta vista de Todo List es la vista real, que es una aplicación JAK, si ves aquí, contiene un sobre. Así que este sobre es responsable de permitir la comunicación entre esta vista y el canal. Así que si revisas este archivo de sobre, contiene algunos métodos abstractos. Si has probado Todo List antes, debes recordar las acciones que podemos hacer en Todo List, para crear una nota, editar una nota o borrar una nota, y para marcar una nota como completa, algo así. Estos métodos abstractos contienen la definición de cada una de estas acciones que puedes hacer en Todo List. Y esta vista va a estar comunicándose con el canal y va a estar abstraída dentro del canal. Así que esta extensión es una TypeScript, basada en TypeScript. Así que sí, simplemente inicia esta vista. Así que si ves este package Json, Todo List view se instala como una dependencia y en la extensión simplemente se importa aquí y simplemente se inicia, eso es todo. Así que el canal no hace nada más que eso. Es tan simple como eso. Y si tomas otro ejemplo de vista de ping-pong, de nuevo, esta vista de ping-pong es la vista real que es el componente React va a contener todos los archivos TSX. Y para esta vista de ping-pong tenemos dos tipos que es uno con iframe y el otro con div, para que puedas probar ambos métodos. Así que en mis diapositivas anteriores también mencioné lo mismo. Así que esta multiplicación architecture logramos evitar el uso de iframes.

8. Implementación de Microfrontend y Ejemplos

Short description:

Usamos div para que nuestra interfaz de usuario se vea más realista. La idea básica de Microfrontend es utilizar diferentes etiquetas de texto. En una aplicación de interfaz de usuario, debes ser capaz de incorporar marcos como Angular y React, pero aún así, para el usuario, debería parecer una sola aplicación. Este ejemplo muestra la combinación de ejemplos individuales en una aplicación de aplicación web, con páginas separadas para cada canal. Puedes probar diferentes opciones e incluso explorar el editor BPMN-DMN en diferentes plataformas.

Usamos div para que nuestra interfaz de usuario se vea más realista. No parece antiguo o algo así. Así que esta vista de ping-pong angular, de nuevo un canal. La vista de ping-pong React es de nuevo un canal. La idea básica de Microfrontend es de nuevo utilizar diferentes etiquetas de texto.

En una aplicación de interfaz de usuario, debes ser capaz de incorporar marcos como Angular, React pero aún así, para el usuario, debería parecer una sola aplicación. Así que eso es de nuevo una de las responsabilidades principales de usar Microfrontend. Eso es lo que estábamos tratando de lograr como parte de esta multiplicación architecture.

Para probar este ejemplo en particular, puedes probar este ejemplo de ping pong, que te dará más idea. Vamos a entrar en esta aplicación de aplicación web y ver cómo todos los ejemplos individuales se combinan en ella. Así que hay una carpeta de páginas dentro de esta aplicación web, que crea páginas individuales para cada uno de los canales que tenemos. Así que para ping pong, base64, tudoless, etc. Como tengo esta aplicación en ejecución, simplemente pasaré por el navegador y veré cómo se ve. Así que sí, este es el tudoless. React Day Berlin es increíble. Solo agregaré esta nota. Tal vez solo la marque como completa. Remoto. Eliminado con éxito. Así que puedes probar ping pong React iframe1 y dev1. De manera similar, puedes probar Angular iframe1, dev1. Así que sí, tienes muchas opciones aquí para probar. Y para demostrar en nuestro equipo, como mencioné, estamos construyendo editores o herramientas, BPMN y editores DMN, así es como podemos renderizar esos editores en diferentes plataformas utilizando múltiple architecture. Así que en caso de que quieras probar este editor BPMN, puedes ir a com.webstore y buscar este editor BPMN-DMN. Habrá esta extensión que puedes instalar. Como ya lo he instalado, puedo ir directamente a bpmn.new. Así que esto carga mi editor. Puedes agregar las notas aquí y crear un proceso de automation empresarial. Te mostraré cómo se ve en VS Code también. Así que este es de nuevo el editor.

9. Abordando la Duplicación de Carga de Biblioteca

Short description:

Nuestro objetivo final era utilizar el mismo editor de componentes web en múltiples plataformas. Sin embargo, nos enfrentamos al problema de la duplicación de la carga de la biblioteca al combinar micro frontends en una única aplicación contenedora. Para abordar esto, utilizamos módulos federados en webpack para compartir dependencias entre micro frontends. Al cargar de forma perezosa los componentes de micro frontend e implementar el marco de arquitectura multiplicador, logramos nuestro objetivo de ejecutar editores en varias plataformas con cambios mínimos de código y cerrar la brecha entre diferentes pilas tecnológicas. El código para esta implementación se puede encontrar en el repositorio proporcionado.

El mismo editor, si observas de cerca la interfaz de usuario de este editor, es el mismo componente web que se utiliza en ambas plataformas, así que eso era lo que queríamos al final. Incluso después de lograr esto, había una preocupación que queríamos abordar, la duplicación de la carga de la biblioteca. Así que si recuerdas la estrategia de integración de la que estábamos hablando, estos son los problemas que teníamos con ambas estrategias de integración que estábamos discutiendo. Lo común entre estos es la duplicación de la carga de la biblioteca.

¿Qué significa eso? Imagina si tienes varios micro frontends en tu aplicación y cada micro frontend tiene a React como una dependencia. Cuando combinas todos estos micro frontends en una única aplicación contenedora, solo imagina el tamaño que va a tener esta aplicación contenedora. ¿Verdad? Solo una dependencia que se duplica en los micro frontends está bien. Pero aún así, si tienes un mayor número de dependencias que se duplican en los micro frontends va a ocupar un gran espacio, ¿verdad? Y también ralentizará tu aplicación, no tienes que hacer eso.

También queríamos evitar este problema, ahí es cuando los módulos federados vinieron a nuestro rescate. Ya habrías oído hablar de estos módulos federados, que se lanzaron como parte de webpack y que nos permitieron compartir las dependencias entre los micro frontends. Así es como se ve la configuración de webpack. El módulo federado se importa en la parte superior y aquí en la sección de plugins, puedes simplemente crear una nueva instancia para el módulo federado. Y puedes compartir las dependencias aquí, apuntando a tus paquetes y dependencias. Y para cargar de forma perezosa tus componentes de micro frontend, siempre puedes usar esta característica de carga perezosa de React para que solo puedas renderizar la interfaz de usuario del micro frontend cuando se visite ese micro frontend en particular. No tienes que cargar todo de una vez al principio para que simplemente se cargue en tu aplicación de todos modos. No tienes que hacer eso. Puedes simplemente renderizarlo cuando sea necesario o cuando se visite.

Entonces, después de implementar todas las estrategias de micro frontend y desarrollar un nuevo marco de arquitectura multiplicador y luego, de nuevo, utilizando módulos federados, finalmente, pudimos lograr nuestro objetivo final de tener nuestros editores funcionando en varias plataformas que teníamos como objetivo. Y pudimos lograr una distribución múltiple con cambios mínimos en el código. Y también pudimos, quiero decir, cerrar la brecha entre las generaciones de pilas tecnológicas que estábamos utilizando en nuestra aplicación. Sí. Así que estos fueron los logros que pudimos obtener de esta arquitectura multiplicadora. El código que viste aquí reside en este repositorio. Puedes tomar una foto de él y luego puedes probarlo por tu cuenta. En caso de que tengas alguna pregunta, no dudes en contactarme. Gracias.

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
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 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
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 Summit 2022React Summit 2022
23 min
Sharing is Caring: (How) Should Micro Frontends Share State?
Micro frontends architecture is extremely powerful when it comes to splitting large frontend monoliths into smaller, individually deployable blocks, each is owned by an autonomous team and is focused on a business domain. But what about State? We are often told that micro frontends shouldn't share state, as this would make them coupled to each other. However, when it comes to complex UIs, it is not rare to encounter scenarios where state management between micro frontends is necessary. This talk is about finding the sweet spot — In which scenarios it is reasonable for micro frontends to share State? and how should micro frontends share State while remaining decoupled of each other? We discuss & compare different solutions in React.
React Advanced Conference 2021React Advanced Conference 2021
27 min
Micro-Frontends Performance and Centralised Data Caching
Common myths about Micro-Frontends hold that they are bad for performance or that developers implementing this architectural style don’t care about the performance implications because they are focusing on fixing the developer experience and organizational issues rather than focusing on the user experience, however, the reality is altogether different. Micro-Frontends are not inheritably bad for performance and, as is often the case in software development, making best use of the technology depends on correct implementation. This talk will demonstrate how Micro-Frontends can make your applications faster and more resilient while keeping the benefits of independent deployments.
React Summit 2022React Summit 2022
25 min
React Microfrontend Applications for TVs and Game Consoles
DAZN is the fastest-growing sports streaming service and during this talk, we will consider our experience building tv applications (for ps5, xbox, LG, Samsung and other targets) with micro frontend architecture. You may expect time travel to see how it started and what we have at the moment, what makes tv development different compared to the web, same as techniques that allow us to share code between targets. You will learn how we test our application with an in-house remote testing lab as well as our deployment and release process.

Workshops on related topic

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.
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.