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

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.

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.

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.

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.

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.

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.

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.

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.

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.