Libertad de plataforma con Micro-frontends

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.

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.

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

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.

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

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

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.

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.