Accidentalmente Construimos un Plugin SDK para Micro Frontends

Bienvenidos a todos a la, como se mencionó, última charla de al menos esta pista. Estoy, ante todo, súper emocionado de estar aquí. Una de las razones es que esta es realmente la primera vez que hablo en una conferencia, y la otra razón es que compartiré cómo construimos accidentalmente un SDK de plugins para microfrontends, al que me refiero como microfrontends en esteroides, pero la responsabilidad en mí puso la advertencia, así que realmente malo.

Una breve introducción sobre mí, mi nombre es Andre, soy ingeniero principal en Betamax, que es una empresa de tecnología educativa con sede en Berlín y resulta que ha construido los sistemas de aprendizaje y enseñanza adaptativos más avanzados del mundo para escuelas. Así que además de, como se mencionó, construir productos digitales, me encanta construir cosas reales también, así que en caso de que ya te canses de hablar sobre código, entonces contáctame y podemos hablar sobre carpintería o deportes acuáticos para el caso, pero volviendo al tema, ¿cómo llegamos allí?

Para responder a la pregunta, quiero darte un poco de contexto del problema que estamos tratando de resolver y cómo terminamos en la posición de tener que resolverlo en primer lugar. Así que soy viejo, lo cual no es la causa raíz del problema, por supuesto, pero significa que en 2008, cuando Betamax comenzó el desarrollo, yo estaba entre los primeros desarrolladores que, que nos pusieron en marcha y construimos una aplicación tradicional de múltiples páginas impulsada por PHP, lo que nos llevó bastante lejos.

De hecho, tan lejos que cuatro años y medio después, pudimos anunciar que Uruguay había elegido a Betamax para proporcionar todo el material de matemáticas para todas las escuelas, lo cual fue un gran logro en aquellos días, pero también significó que tendríamos un problema bastante pronto porque, según los datos que obtuvimos en Alemania, sabemos que esta configuración no escalaría al nivel de todo un país. Así que pensamos que sería una buena idea construir una aplicación de una sola página, lo último en aquel entonces. Por casualidad, ¿alguno de ustedes sabe cuándo React fue de código abierto? Un mes después. Así que creo que es hora de abordar el elefante en la habitación. Estamos en la conferencia de React, pero en ese momento, optamos por la única opción razonable siendo AngularJS.

Así que, de hecho, construimos la aplicación, la lanzamos y hemos construido sobre esta base desde entonces, en realidad. Pero avanzando rápido, nueve años después, lo inevitable sucedió y Google descontinuó el soporte a largo plazo para AngularJS. Quiero decir, bastante tiempo para ser justos. En ese momento, ya había regresado a Betamax, con la misión de idear un plan de cómo migrar iterativamente de AngularJS a React. Así que abogué por un enfoque de micro frontend y lo ejecutamos con un solo span, que es básicamente un enrutador de JavaScript para micro servicios en el frontend. Y se diferencia, entre otras cosas, en diferentes tipos de microfrontends, que explicaré rápidamente porque usaré la terminología en adelante.

Así que tenemos aplicaciones, por supuesto, que son como cualquier otra aplicación de una sola página, pero sin una página HTML real. Tenemos una configuración raíz que proporciona esta página HTML raíz, maneja el registro de aplicaciones, montaje, desmontaje. Así que es responsable de toda la composición de la configuración de micro frontend. Luego tenemos utilidades para compartir lógica común y como servicios o biblioteca de componentes y tenemos analizadores para compartir UI entre marcos. Esto será importante más adelante. Nuestra prueba de concepto fue bastante fácil de hacer. Así que implementamos la navegación en React y mantuvimos el área de contenido como una versión reducida de AngularJS con un proceso de arranque a medida para la aplicación, que funcionó bastante bien.

Así que pusimos a todo un equipo en ello y comenzamos a desarrollar rápidamente hasta este punto. Ahora ejecutamos una configuración completa de micro frontend donde las aplicaciones pueden renderizar partes dentro de otras aplicaciones donde actualmente tenemos 58 microfrontends y seguimos contando. Tenemos servicios, microfrontends de utilidad que proporcionan APIs compartidas, incluyendo gestión de estado global y detrás de escena, hacemos esto con RxJS bastante intensamente. Y sí, todavía tenemos algunos casos de uso en AngularJS, desafortunadamente, pero estamos llegando allí. Sí, te lo prometí. Lo sé.

Um, pero primero, ¿qué estamos tratando de lograr realmente desde una perspectiva de objetivos? Así que, um, queremos tener poco o ningún acoplamiento entre aplicaciones. La configuración raíz es el único lugar que controla la composición de las aplicaciones. Queremos ser adaptables. Eso significa, um, la composición de estas aplicaciones se basa en roles, permisos, licencias, toggles de características y configuraciones para que diferentes usuarios puedan tener potencialmente diferentes experiencias de usuario. Y desde un punto de vista arquitectónico, queremos, apuntamos a la separación de preocupaciones, encapsulación y contexto delimitado a nivel de micro frontend.

Sí. Así que sin más preámbulos, pensé que sería una buena idea para tu primera charla ir con una demostración en vivo porque, ¿por qué no? Um, así que esto es Better Marks desde la perspectiva de un estudiante. Estamos viendo una de las vistas más odiadas por los estudiantes porque cuando algo aparece allí, generalmente significa tareas. Y el contenido allí es solo una de las vistas más odiadas por los estudiantes. Y el contenido allí es de nuestro producto de práctica. También tenemos otro que se llama Teaching a School Book, que es un reemplazo digital para los libros escolares físicos de los estudiantes.

Um, la línea roja en la parte superior marca un punto de extensión que llamamos ranuras de portal. Nada aparece aquí. Y te mostraré por qué, porque el toggle de características no está activo. Así que si activo este toggle de características y recargo. Así que ahora aparece contenido. Sí, justo. Así que esto es material que los profesores distribuyeron a los estudiantes para que lo vean. Y para entender nuestro enfoque, te guiaré a través del proceso de arranque de esta página. Ahora ya viste el toggle de características. Así que la configuración raíz se encarga de registrar aplicaciones, como mencioné. Así que tiene, uh, conoce al usuario. Por lo tanto, conoce las licencias potenciales y si la licencia coincide o es suficiente, también registramos la aplicación de tareas, lo que acabamos de ver, el material de tareas. Luego, para el toggle de características activado del libro escolar, también, um, registramos la aplicación de unidades de aprendizaje que proporciona el contenido distribuido, um, del producto del libro escolar, si una aplicación registrada está activa o no, se determina por señales bar para ello ejecutando la función is active para cada aplicación registrada. Y en este caso, um, la ruta para las tareas y las unidades de aprendizaje asignadas coinciden. Así que ambos están montados en esta vista. Si ahora una vista quiere ofrecer una de estas ranuras de portal, solo tienen que usar nuestra tienda de portal con la ranura deseada, lo que les dará un ref de callback. Un componente que quiere renderizar en uno de esos puntos de extensión, también conocidos como ranuras de portal, usa nuestro renderizador de portal para obtener una función create portal personalizada que se encargará de renderizar tu contenido en el nodo DOM correcto una vez que esté montado. Y la parte realmente interesante ocurre en nuestro servicio de portal.

Por lo tanto, necesitas saber qué es un behavior subject, porque esto es en lo que se basa. En RxJS behavior subjects que usamos para publicar nuestro conjunto de puntos de extensión montados, um, se asegura de que cada suscriptor siempre obtenga un valor. Así que una vez que te suscribes, obtienes el inicial que es un mapa vacío, o si llegas tarde a la fiesta y ya se ha publicado algo, aún obtendrás el valor más reciente, lo cual es importante tener en cuenta cuando hablamos de tiempo.

Um, nuestro hook use portal store que es responsable de proporcionarte el ref de callback, por otro lado, se encarga del ciclo de vida de este componente. Así que si está montado, estamos viendo esta línea aquí. Entonces activará un dispatch o activará una publicación del mapa actualizado actual de ranuras de portal montadas en ese almacenamiento. Y si, y si el nodo objetivo se desmonta, se eliminará del mapa de ranuras de portal disponibles y también lo publicará en, en este portal store.

En el extremo consumidor de las cosas, el portal renderer, por otro lado, este se suscribirá con una ranura de portal deseada en ese almacenamiento. Y si hay un nodo DOM montado donde podría renderizar, entonces devuelve la función react-create portal para que pueda ser utilizada en el componente, um, para renderizar en el nodo objetivo deseado. Y en realidad eso es todo. Como 80 líneas de código que tomaron bastante tiempo en idear. Y si no estás tan emocionado como yo cuando lo logramos, no te culpo pero, uh, escúchame.

Así que un resumen rápido, la aplicación responsable de la vista principal ofrece una o más ranuras usando nuestros portales anteriores, de los que hablamos. La aplicación responsable de la vista principal ofrece una o más ranuras usando nuestros hooks de servicio de portal. Lo que se representará en esas ranuras depende de micro frontends registrados y micro frontends montados. La salsa secreta es que al publicar ranuras montadas en un RxJS behavior subject, eliminamos problemas de sincronización con paquetes cargados de manera perezosa y el orden de representación, porque si imaginas que tienes una gran configuración con diferentes micro frontends cargándose de manera perezosa, debes asegurarte de que por un lado, el nodo objetivo debe estar montado, pero también la aplicación que se cargará de manera perezosa y por lo tanto llega tarde a la fiesta, como dije, um, también en algún momento sabe cuándo y dónde representarse. Y al tener estos, um, contextos delimitados o paquetes aislados, um, en, um, paquetes aislados, también aislamos errores de tiempo de ejecución. Y lo que eso significa, um, es que en caso de que un desarrollador cometa un error y sé que esto apenas sucede, pero, um, en caso de que suceda, lo único visible para el usuario es que falta algún contenido en caso de tareas, los estudiantes estarán felices. Usualmente los profesores no lo estarán, pero toda la aplicación sigue funcionando porque está aislada en solo una aplicación que está usando un punto de extensión. Así que si piensas en este enfoque a gran escala, significa que tu aplicación o nuestra aplicación al menos es bastante resistente a errores humanos o problemas de infraestructura como puntos finales no disponibles o paquetes que podrían no haberse cargado. Um, y además, es súper fácil determinar o predecir el estado de tu aplicación porque tenemos exactamente un lugar donde se determina la composición, que es la configuración raíz. Y por lo tanto, es, y allí se basa en licencias y toggles de características como mencioné. Así que se puede probar fácilmente. Y desde una perspectiva de producto, por otro lado, si tienes bastantes de estas, uh, aplicaciones responsables de contextos delimitados, eso significa que puedes usarlas en diferentes composiciones para construir diferentes casos de uso.

Y creo que tenemos tiempo para una cosa más porque no sé si alguien leyó todo el pitch. También afirmo que podemos renderizar REC.js dentro de AngularJS. Y sí, aquí estamos. Estos, los bonitos widgets en la parte superior son widgets de nuestra aplicación de enseñanza renderizados dentro de la aplicación AngularJS de la vieja escuela. Y ahora espero que hayas prestado atención. Um, cómo hacemos esto es súper sencillo. Um, tenemos el concepto de pases. Te dije dónde podemos compartir la interfaz de usuario entre diferentes frameworks. Así que creé un paquete que no hace nada más que proporcionar una ranura de portal. Este portal, paquete de portal, nombrar es realmente difícil, um, puede ser importado en AngularJS usando system.js. Por lo tanto, nosotros, y con este enfoque, obtenemos las funciones del ciclo de vida. Configuramos las propiedades del paquete que se necesitan y en la plantilla de AngularJS.

Sí, así es como se ve una plantilla de AngularJS. Podemos usar una directiva de elemento de paquete. Y así es como se llama en AngularJS que se encargará de renderizar tu paquete. Afortunadamente, single-span ofrece esto para muchos, para bastantes frameworks, de hecho. Así que switch, view, lo que sea. Pero a partir de ahí, es volver a lo que ya viste. Así que tendremos un componente de React siendo un informe de la ranura en AngularJS y todo lo demás es lo que acabas de ver. Así que bastante fácil, bastante sencillo, pero fue un gran efecto. Y de hecho, tres minutos antes, pero esto es todo lo que tengo por hoy.

El código QR te lleva a un gist que creé en GitHub donde encuentras el servicio de portal este es un ejemplo muy básico. Así que puedes jugar si quieres. Contáctame en LinkedIn, si tienes preguntas o más tarde, quiero decir, mejor en el rincón de preguntas y respuestas del orador, pero sí, eso es todo. Muchas gracias. Fue una charla tan buena. Y lo que también fue hilarante es que durante la charla estaba escuchando y estabas describiendo por lo que estabas pasando. Era como, sí, es un micro frontend. Oh sí. Ese es el punto de esta charla.

Accidentalmente construiste un SDK de plugin para micro frontends. Eso fue realmente interesante cuando comenzaste a hablar sobre Angular, yo estaba como, ¿a dónde vamos con esto? Y tú estabas como, oh, sí, ese es un buen punto. De hecho, tenemos un montón de preguntas llegando. Recuerda también que puedes calificar las charlas también. Así que un cinco de cinco también sería genial. Y vamos a sumergirnos directamente en nuestro contenido.

Entonces, la primera pregunta fue sobre los diferentes micro servicios que tienes y cómo, ¿pueden comunicarse entre ellos, hay formas en que pueden hacer saber a otro tipo de micro frontend o pieza que algo está sucediendo? Sí. Así que mencioné los servicios, micro frontend de utilidad. Este, hay bastantes servicios de React que usan RxJS bajo el capó. Así que cada vez que quieras tener comunicación entre aplicaciones, lo harás a través del servicio porque este siempre estará montado, por lo que está en, tiene comunicación entre aplicaciones. Así que está en, tiene un estado que se persiste y con RxJS realmente puedes construir pipelines realmente agradables a través de la transformación, filtrado, y puedes notificar básicamente sin acoplarte a otra aplicación, simplemente puedes lanzarlo allí y las partes interesadas podrían suscribirse a estos eventos y actuar en consecuencia.

Eso tiene sentido. Eso tiene sentido. Y luego otro tipo de pregunta que ha llegado, esta es de Ross. A menudo, cuando trabajas con micro frontends, el despliegue se vuelve un poco complicado y puede convertirse en un gran problema. ¿Cómo manejas el despliegue de cada uno de estos micro frontends y una aplicación de show y se despliegan juntos o por separado? Así que nos encantaría estar en un estado donde podamos desplegar solo un conjunto de micro frontends afectados.

No estamos allí todavía, desafortunadamente, porque esto tiene solo dos años y medio o así, por lo que actualmente desplegamos todos los frontends juntos. Apuntamos al despliegue que acabo de mencionar donde, ya sabes, has actualizado un micro frontend y otros dependen de ellos, así que sabemos, está bien, tenemos que desplegar estos cuatro. Sí, eso es todo. Hacemos un despliegue de una sola vez para los 58. Genial. Voy a guardar la pregunta de la camiseta para más tarde, pero llegaremos a ella. Lo prometo a quien preguntó, um, y luego otra pregunta de Ross nuevamente, que fue sobre cambios importantes. Entonces, ¿cómo manejas los cambios importantes entre micro frontends y la aplicación principal? ¿Y a qué aplicación principal? Aplicación principal.

Bueno, si un equipo quiere introducir un cambio importante en su, en el microfrontend del que son responsables, tienes que empezar a hablar con otros equipos y luego asegurarte de que, como desplegamos de una vez, también proporciones que también abordes estos cambios importantes y los mitiges.

No, absolutamente. Creo que esto es interesante porque, y quiero añadir a esta pregunta donde están las partes técnicas y luego también está la gestión del equipo, lograr que el equipo trabaje junto a esta pregunta. Sí.

Así que imagina, dije que tenemos 58 micro frontends. Eso significa que obviamente no somos solo un equipo trabajando en estos. Así que tenemos, creo que ahora cuatro o cinco equipos trabajando en este monorepo. Y así hay mucha conversación en curso, semanalmente y bajo demanda. Así que sí, necesita algo de coordinación seguro, pero también lleva, um, lleva a un buen intercambio entre esos equipos. Absolutamente. El trabajo en equipo y la colaboración siempre son la clave. Siempre la clave.

Uh, la siguiente es sobre los entornos de desarrollo local, uh, especialmente porque tienes, uh, bastantes cosas diferentes en marcha. Entonces, ¿cómo, uh, estás manejando o cómo están los diferentes miembros de los equipos manejando, uh, los entornos de desarrollo local entre estos diferentes micro frontends?

Bueno, depende. Um, desearía tener la puerta para cada vez. Sé esa respuesta. Sí. Así que cuando te enfocas principalmente en el trabajo de front, um, lo que acabas de ver fueron mis, um, lo llamamos micro stack en funcionamiento, que es, que es un backend simulado completo, basado solo en Node. Realmente simple. Um, hay otros, uh, cuando quieres, quieres trabajar full stack, tenemos, um, tenemos un stack de escritorio de Kubernetes que se supone que debe ejecutarse en tu máquina completamente con todo el backend efectivo que necesitas, porque también en el lado del backend, tenemos microservicios. Um, así que sí, estas dos opciones lo ejecutan completamente localmente con backend simulado o, um, la aplicación completa.

Y supongo que eso probablemente es algo que comenzará a incluir la preferencia de usuarios particulares o lo que necesitan en qué punto en el ciclo de desarrollo también, desarrollo. Sí, justo decir. No, seguro. Seguro.

Y otra pregunta es sobre la federación de módulos. ¿Has considerado usar el concepto de federación de módulos para compartir código entre parcelas? Bueno, creo que lo que podría, debería haber mencionado con respecto a las parcelas es que intentamos, no intentamos, nos mantuvimos alejados de esto tanto como fue posible. Y este ejemplo muy específico que acabas de ver fue hecho únicamente por mí para propósitos de demostración para ser realmente transparente aquí porque añade una capa completa de complejidades que intentamos evitar. Así que, porque siempre es una solución intermedia. Nuestro objetivo es deshacernos de AngularJS muy pronto.

Así que no queremos hacer que sea tentador para las personas de producto proponer nuevas ideas de características donde simplemente puedas poner un parcel allí y aquí vamos. Así que no lo hemos considerado. No usamos, no usamos parcels en nuestra aplicación de producción. Y eso en realidad me hizo recordar que toda la razón por la que comenzaron es por la migración. Esa es la fuerza impulsora y equilibrar la migración con avanzar debe ser algo interesante que tu equipo tiene que enfrentar. Sí, es interesante, exigente en todos los niveles. Así que una vez tenemos que comunicar a las personas de producto que no tocaremos esta base de código a menos que tengamos errores graves. Así que no desarrollamos características en la base de código heredada y vamos de un uso, un caso de uso tras otro en términos de migración. Así que no hay pequeñas mejoras simplemente añadiendo algunas cosas de React a nuestra base de código existente.

Interesante. Ahora, esta es una pregunta un poco diferente que trata sobre lo que estás construyendo y más sobre cómo lo estás probando. Y nos mostraste la configuración y cómo puedes cambiar entre diferentes permutaciones de configuración. Y esta persona ha preguntado, ¿cómo manejas las pruebas de extremo a extremo entre todas estas diferentes permutaciones de configuración? Así que pasamos por toda la pirámide de pruebas. Así que usamos react testing library para pruebas de bajo nivel, para hacer y usamos pruebas de snapshot para probar lo que esperaríamos para micro frontends montados para cada ruta y un nivel más alto. Decimos, está bien, hacemos pruebas de integración para cada configuración donde al menos dos micro frontends están involucrados además del de navegación que siempre estará montado. Y luego, en la última etapa, hacemos las pruebas de extremo a extremo realmente costosas solo para pruebas de humo. Así que tenemos una suite de pruebas de integración bastante extensa.

Sí. Y me encanta cómo usas el nivel correcto de resolución con tus pruebas para lo que necesites. Y esto se relaciona con otra pregunta que llegó, que era sobre probar la interacción entre micro frontends. Así que hablaste sobre poder seleccionar la prueba cuando estos dos micro frontends están involucrados. ¿También puedes probar las interacciones entre ellos? Bueno, si quieres probar las interacciones entre ellos, tienes que confiar en pruebas de integración porque esto está a nivel de prueba unitaria. Simplemente no puedes.

Tienes que simular. Genial. Otra pregunta.

Casi se nos acaba el tiempo, así que esta será la última antes de llegar a la pregunta más importante bajo esto. ¿Puedes tener diferentes versiones de React para cada micro front end o los micro servicios, micro front ends, supongo, comparten una versión de React?

Ahora, gran pregunta. Estaba esperando esta. No. Así que esta es una de las limitaciones básicas o una de las limitaciones más importantes que debes tener en cuenta. Tenemos un React y una versión de React solamente, que es una llamada dependencia compartida, lo que significa que, por supuesto, no está empaquetada con cada micro front end. Así que tenemos una versión de React, una versión de AngularJS, nada más. Así que sí, actualizar esto puede ser bastante difícil cuando piensas en 58 micro front ends, pero así es como es.

Genial. Y honestamente, cuando lo vi en la diapositiva, no me di cuenta del chiste del elefante en la habitación, pero luego de ver tu camiseta, realmente, realmente lo entendí. Para aquellos de ustedes que tal vez están en la parte de atrás, no pueden ver, su camiseta es el esquema o el plano de una habitación, pero si miras de cerca o entrecierras los ojos, realmente puedes ver un elefante en esa habitación y es una camiseta realmente genial. ¿De dónde la sacaste? Sí, es un diseñador de camisetas de, creo que Nueva Zelanda originalmente, se llama Glenz, G L E doble N Z. Así que, y una vez al año pido un montón de camisetas y las envío desde los EE. UU. Así que, Genial. Me encanta, me encanta esa camiseta. Y si tal vez quieres averiguar dónde puedes conseguir esa camiseta, puedes encontrarlo en la sala de preguntas y respuestas del orador más tarde, pero también, ¿dónde puede la gente encontrarte en línea si quieren seguir el trabajo que haces? Pero, o sea, principalmente en LinkedIn, mi trabajo, no tengo realmente, no tengo mucho que publicar porque mi enfoque principal es better marks y esto no está en abierto. Puedes intentar enviarme un DM en Twitter, es defthisdog, pero no estoy realmente activo allí. Bueno. Está bien, LinkedIn y también encuéntralo en persona. Y si estás en línea, también puedes unirte a las preguntas y respuestas de los oradores virtualmente también. ¿Podemos darle un aplauso más? Un gran aplauso.