Compartir es Cuidar: ¿Cómo Deberían los Micro Frontends Compartir Estado?

Hola a todos. Mi nombre es Eliran Atan. Esta es mi segunda vez en el Summit de React, pero aún estoy muy emocionado. He estado construyendo sistemas escalables durante la última década, y hoy deseo centrarme en los micro-frontends, y especialmente sobre el estado compartido de los micro-frontends.

Entonces, los micro-frontends se tratan de romper este monolito de frontend en piezas más pequeñas y manejables que permiten a los equipos de desarrollo trabajar de una manera más eficiente y efectiva. Esto se debe a que los micro-frontends a menudo están aislados entre sí. Permiten a los equipos de desarrollo trabajar de manera autónoma y con menos fricciones y limitaciones.

Un problema común que a menudo surge cuando hablamos de micro-frontends es si deberían compartir estado o comunicarse de alguna manera. Si es así, ¿cómo deberíamos hacerlo sin romper su aislamiento entre sí? Ahora, en esta charla veremos un enfoque diferente para pensar en los micro-frontends. Vamos a abordarlo desde una perspectiva orientada al dominio. Entonces, veremos cómo podemos representar un micro-frontend usando algo que llamamos un contexto delimitado. El contexto delimitado es esta criatura lógica que refleja nuestra implementación y puede derivar la implementación. Y veremos cómo eso puede ayudarnos a entender la comunicación entre los micro-frontends.

Entonces, comencemos desde otro ángulo. Hablemos de Agile. En Agile, a menudo trabajamos con historias de usuario. Entonces, las historias de usuario son esta breve descripción de un objetivo final que el usuario quisiera lograr, ¿verdad? Y siempre se describe desde la perspectiva del usuario y en términos de el negocio. Entonces, generalmente en muchas organizaciones, resolver una historia de usuario implicará la cooperación y coordinación de equipos de múltiples capas. Y eso es porque el código afectado al resolver esa historia a menudo se comparte entre estos equipos. Y eso es debido a cómo las organizaciones tienden a estructurar los equipos, especialmente cuando hablamos de front-end. A menudo vemos esta división arbitraria de responsabilidades entre los equipos. A veces se trata de poseer componentes o páginas o vistas. Pero eso no es realmente cómo se organizan las historias de usuario. Lo que realmente queremos es alguna forma de organizar nuestros equipos y código de manera que resolver una historia de usuario sería una tarea de principio a fin de un solo equipo. Eso significa que el código afectado al resolver esa historia pertenecería a un solo equipo. Eso haría un flujo mucho más agradable, especialmente a escala. Una pregunta que deberíamos hacernos es cómo se organizan las historias de usuario. Desde una perspectiva orientada al dominio, las historias de usuario se organizan de acuerdo a los subdominios. Si solo tomamos una aplicación estándar de e-commerce, eso es el dominio más simple que podemos pensar, entonces una división normal a subdominios sería algo como un catálogo, orden, entrega, soporte, y quizás algunos otros subdominios. El subdominio del catálogo se preocupa por permitir a los usuarios navegar y buscar productos, mientras que los otros subdominios se preocupan por los usuarios que lanzan productos en

Ahora, eso puede llevarse más allá, y aquí es donde volvemos a hablar de microfrontends. al dividir este monolito en diferentes microfrontends eso mejorará la segregación que hacemos entre entre subdominios, y también dará a los equipos un nivel adicional, otro nivel de autonomía en el nivel de la pila tecnológica porque ahora pueden elegir sus propias herramientas y en los patrones de diseño por ejemplo. Cada equipo puede optimizar los patrones de diseño que utiliza para el objetivo específico, los objetivos específicos que quiere lograr.

Entonces, mi punto aquí es que un terreno sólido para el microfrontend es considerar la alineación con aspectos comerciales. Es por eso que cuando hablamos de microfrontends tenemos que pensar en el diseño orientado al dominio, específicamente sobre el DDD estratégico. Entonces, el DDD estratégico es este conjunto de herramientas que nos permite descomponer correctamente nuestro dominio en varios subdominios de una manera que maximizará el potencial que tiene el microfrontend. DDD realmente nos dice reunir a nuestros expertos en dominios para tomar el tiempo y hacer una lluvia de ideas junto con otros interesados para formar este lenguaje inequívoco que realmente captura las entidades naturales y procesos que ocurren dentro de este subdominio. Y este lenguaje forma es un límite lógico que llamamos contexto delimitado. El contexto delimitado tiene mucho que ofrecer, muchos beneficios para trabajar con el contexto delimitado y derivar de ellos la implementación real del microfrontend. Entonces, cada contexto delimitado derivará una implementación de un cierto microfrontend. Podríamos resumir eso diciendo que un microfrontend es una implementación técnica de un contexto delimitado. Entonces, tener un contexto delimitado que derive microfrontends tiene numerosos beneficios. El contexto delimitado puede simplificar drásticamente la implementación de cada microfrontend porque cada término en cada contexto delimitado se describe desde la perspectiva de ese contexto delimitado. Entonces, no tienes mucha información redundante que necesitas manejar. Solo manejas las cosas que son relevantes dentro de ese contexto. Y hay un beneficio más profundo para eso. Y ahora tenemos esto en cada contexto tenemos un lenguaje cohesivo inequívoco que todos entienden. Y eso hace que la comunicación sea mucho mejor. Y eso hace que sea mucho más fácil traducir las historias de usuario y así sucesivamente.

Pero quiero centrarme en otro beneficio que se relaciona con cómo debería comunicarse un micro-frontend. Tenemos otra herramienta que es parte del kit de herramientas DDD es la herramienta de mapeo de contexto. El mapeo de contexto se trata de entender, hacer una lluvia de ideas y entender las relaciones entre diferentes contextos. Entonces, por ejemplo, aquí aunque el término producto generalmente significa algo más, algo específico cuando hablamos de contexto de catálogo, por ejemplo una estructura que muestra todos los comentarios, reseñas, detalles del producto, imágenes del producto, y así sucesivamente, eso significa que el producto significará algo más en el contexto de la orden. Probablemente tendrá algún id, precio, descuentos, o todo lo que se relaciona con la orden. Pero aún así, aunque están definidos de manera diferente en esos diferentes contextos, todavía tienen esta conexión lógica entre ellos, ¿verdad? Porque queremos permitir a los usuarios dejar productos que encuentran en el catálogo en algún carrito que es naturalmente parte del contexto de la orden. Y eso puede ser, eso realmente realmente deriva una comunicación que debemos tener entre el front-end del catálogo y el front-end de la orden, ¿verdad? Esa pieza de información, un producto seleccionado, tiene que ser comunicada entre estos micro front-end. Entonces, vemos aquí una forma de entender lógicamente cuáles son las conexiones que debemos hacer entre los contextos, y luego derivar de allí la comunicación entre la implementación, entre los micro front-end reales. Y eso puede ayudarnos a evitar la comunicación innecesaria, y también puede ayudarnos a entender si nuestro modelo es correcto, si no estamos creando demasiado

Entonces, hablemos de la comunicación directa entre microfrontends. Este es un problema muy general en la ingeniería de software. Tenemos estas diferentes unidades que son independientes entre sí. No queremos que estén acopladas entre sí, pero aún tienen que pasar mensajes entre sí porque son parte de un equipo más grande.

Entonces, si echamos un vistazo a lo que estamos haciendo en el diseño de software de backend, generalmente se trata de microservicios y micro frontend y los microservicios tienen alguna correlación entre ellos. Esa es una oportunidad para aprender mucho sobre microfrontends. Entonces, si echamos un vistazo a cómo se comunican los microservicios, uno de los patterns más populares y poderosos es el mecanismo de suscripción pública, mensajería asíncrona. Cada microservicio puede publicar información, cosas interesantes que suceden dentro del microservicio en algún espacio compartido, como un bus de mensajes, y cualquier otro microservicio podría consumir esta información en caso de que sea realmente interesante. Entonces, esto hace que los microservicios aún se desacoplen entre sí de alguna manera, pero aún permite una comunicación muy agradable y muy poderosa. Entonces, podríamos derivar de eso una solución para nuestros microfrontends, ¿verdad? Podríamos usar el objeto window, que es un gran espacio común con el que cada microfrontend puede comunicarse. Y cada microfrontend podría publicar eventos interesantes sobre cosas que suceden, como un producto que se seleccionó para la tarjeta, y cualquier otro microfrontend podría consumir esta información. Entonces, diferentes microfrontends no son conscientes el uno del otro, pero aún pueden pasar información importada. Entonces, eso se puede implementar muy fácilmente e incluso de forma nativa usando eventos personalizados. Podemos crear eventos personalizados y enviarlos a la ventana, y podemos agregar oyentes de eventos a la ventana para recuperar esta información. Entonces, podrías envolver ese mecanismo con tu marco React o Vue y construir algo más advanced que pueda ayudarte a automatizar parte de esta comunicación o hacerla más robusta.

Ahora, eso estuvo bien, pero a veces, simplemente tienes que tener un estado. Entonces, comunicarse con el evento es genial, pero hay algunas operaciones complejas o algunos constructos complejos de data que queríamos tener compartidos o algún tipo de estados como un estado de Redux para gestionar el proceso, y eso puede suceder bastante a menudo. Entonces, lo que querríamos es esto una tienda Redux centralizada y cada microfrontend podría comunicarse con para mantener estos tipos de estados complejos. Y esto es muy problemático, especialmente cuando hablamos de microfrontends, porque esto rompe completamente las aislaciones que tienen entre sí, especialmente que son propiedad de diferentes equipos. Entonces, si el producto, microfrontend manipula el estado de alguna manera, entonces el microfrontend de entrega y el microfrontend de soporte tendrían que adaptarse o entender el cambio y eso puede volverse muy difícil. Entonces, lo que realmente queríamos son estas tiendas agradables y alineadas. Tenemos una tienda por microfrontend. Cada microfrontend puede usar esa tienda como una tienda Redux, y estas tiendas están desacopladas entre sí. Pero, por supuesto, aquí no tenemos ninguna comunicación entre ellos y eso también es problemático. Entonces, otra solución que he visto para mantener un estado entre microfrontends de una manera que aún los mantiene bastante desacoplados es permitir que los microfrontends se suscriban o vean las tiendas de otros microfrontends, pero sin la capacidad de mutar estas tiendas. Entonces, en este ejemplo, el microfrontend de soporte puede realmente, el microfrontend de producto, los microfrontends de entrega pueden ver la tienda del microfrontend de soporte, pero aún hay algún problema, hay algunos problemas aquí, porque cualquier cambio en cómo se implementa la tienda de soporte afectaría a los microfrontends de entrega y producto. Entonces, lo que podemos hacer para hacerlo aún más seguro es llegar a esta tienda global. Esta tienda global gestiona las diferentes tiendas de los diferentes microfrontends, cada microfrontend puede suscribirse a la tienda, tiene su propia tienda que puede manipular, y otros microfrontends pueden consumir y suscribirse a sus propias tiendas u otras tiendas. Debido a que esta tienda global expondría una API específica, entonces cada microfrontend solo tendría que implementar esa API específica y eso hará que todo sea mucho más fácil eso alineará esta API en esos diferentes microfrontends.

Bueno, entonces eso fue como una visión general de tres formas comunes de mantener la comunicación entre microfrontends mientras los mantiene bastante aislados entre sí. Entonces, me gustaría resumir la charla y lo primero que decimos es que debemos esforzarnos hacia equipos altamente autónomos, deberíamos estructurar equipos en alineación con los negocios subdominios y eso no se relaciona directamente con microfrontends, definitivamente puedes tener un monolito que está alineado con un aspecto empresarial. Aunque la aplicación de la arquitectura de microfrontend podría mejorar esta idea segregando las preocupaciones comerciales de una mejor manera. Y al aplicar DTD estratégico podemos identificar subdominios, modelarlos en contextos delimitados y aplicar el mapeo de contexto para encontrar relaciones entre ellos. Y también decimos que el microfrontend es una implementación técnica del contexto delimitado. Entonces, el mapeo de contexto puede ayudarnos a identificar los puntos, los puntos de contacto donde el microfrontend debería comunicarse. Y una regla importante es que la comunicación entre microfrontends debería mantenerlos aislados entre sí. Entonces, eso es un resumen de la charla. Espero haber dado algo de inspiration sobre cómo aplicar DDD en problemas que encontramos en el frontend, y cómo facilitar la comunicación entre microfrontends de una manera que te ayudará a alcanzar metas como la autonomía del equipo. Muchas gracias.