Diseñando una Migración a Micro-Frontends

Bien, en los últimos 10 años, trabajé incansablemente para descubrir cómo podemos tener una arquitectura que esté distribuida en el front end. Y créanme, fue un viaje. Así que pasé tiempo implementando, pasé tiempo diseñando Microfront Ends, pasé mucho tiempo recopilando historias de guerra sobre lo que funcionó, lo que no funcionó, definiendo patrones, anti-patrones, definiendo el vocabulario de la arquitectura, definiendo lo que estaba dentro y fuera de contextos específicos que ni siquiera puedes imaginar. Pero hoy estoy extremadamente feliz de decir que las empresas más grandes del mundo están usando esta arquitectura.

Digamos que las herramientas que actualmente están usando el software, las aplicaciones que están usando en cualquier tipo de industria, minoristas, o bancos, seguros, entretenimiento, incluso en deportes, todos ellos en algún momento se trasladaron a Microfront Ends. Y hoy quiero compartir con ustedes un camino pavimentado o un camino dorado que les permitirá hacerlo también.

Así que, la mayoría de las veces, si mi clicker funciona, bien, cuando entro en una sala con un equipo que quiere trabajar con Microfront Ends, la conversación comienza de esta manera. Hemos visto tu trabajo, nos gusta, así que queremos movernos a Microfront Ends. Pero ya tenemos un plan. Esta es nuestra aplicación y simplemente tomamos todos nuestros componentes, los cargamos de forma remota, y oh, trabajo hecho. Mi respuesta suele ser esta.

Así que, buena suerte con eso, porque eso no es un Microfront End. ¿Qué es un Microfront End entonces? Entonces, la mayoría de las veces hay esta confusión de que los componentes son Microfront Ends cuando no lo son. Porque un componente tiene un aspecto de implementación específico. Entonces, cuando implementas el componente, como puedes ver aquí desde esta entrada al código, tenemos este bonito botón que expone un montón de propiedades, el ID, la etiqueta, las funcionalidades, y así sucesivamente. Entonces, ¿qué significa eso? Que en realidad, el contenedor del componente está instruyendo al componente para que se comporte de una cierta manera. Los Microfront Ends no funcionan de esa manera. En un Microfront End, en cambio, tenemos una huella muy pequeña de propiedades. Básicamente, solo tienes un Microfront End que sabe cómo comportarse en un contexto específico. ¿Por qué eso? Porque la realidad es simple. Entonces, un componente está diseñado para la usabilidad. Creas un sistema de diseño porque quieres tener el mismo aspecto y sensación en todas partes. Quieres reducir la duplicación, y finalmente, quieres tener consistencia en la UI, ¿verdad? El Microfront End no es para eso. El Microfront End está optimizado para la independencia. Quieres alcanzar el flujo rápido. Quieres tener independencia entre equipos. Quieres tener un sistema que sea capaz de desplegar múltiples veces al día para múltiples equipos y alcanzar miles de despliegues por mes.

Así que, comencemos con el viaje de migración. Esto es lo que llamo el camino de pivote, y la mayoría de las veces, la gente comienza desde esto. ¿Debería elegir Multi-Federation, Single SPA, Next.js, Multizone, lo que sea? Ese no es el punto de partida. Así no es como diseñas un sistema distribuido de front-end o back-end. Entonces, usualmente, lo que deberías preguntarte es, ¿qué quieres lograr? Porque los sistemas distribuidos son diferentes. Entonces, para ayudarte con eso, pasé los últimos nueve meses trabajando en el lienzo de Microfront Ends. Ayer, lo anuncié por primera vez, y hoy lo muestro por primera vez en un escenario. Este lienzo de Microfront End proviene de la idea de un lienzo de arquitectura de software que usé un puñado de veces en el pasado para tratar de definir cómo definir un límite de un sistema. Esto está diseñado exactamente para Microfront Ends. Es completamente de código abierto. Es un crédito común. Puedes descargarlo hoy y comenzar a usarlo con tu asistente de código o en una masterclass con tus equipos. Básicamente, se centra en los aspectos clave sobre cómo diseñas un límite de un Microfront End. ¿Cuáles son las validaciones de límites? ¿Cuáles son las restricciones organizacionales? ¿Cuáles son las dependencias, específicamente las dependencias externas? ¿Cuáles son las metodologías de comunicación? La pregunta que usualmente deberías hacerte antes de escribir la primera línea de código.

Todo está integrado aquí, y hay una buena guía que describe cómo usarlo. El segundo paso es generalmente entender cuáles son las arquitecturas más comunes de Microfront Ends. Las he recopilado para ti, así que no tienes que hacer ese trabajo. Usualmente, la mayoría de las veces, ya sea que hagas Microfront Ends en renderización del lado del servidor o renderización del lado del cliente, comienzas con un application shell o un UI composer. La responsabilidad de esta pieza de arquitectura es muy simple. Cargas el sitio web. Es lo primero que se carga, ya sea en el servidor o en el cliente. Maneja la configuración, encontrando información como en qué dispositivo estás renderizando. Por ejemplo, el país donde está el usuario, y cosas así. Tienes autenticación, autorización, manejo, centralizado dentro del application shell, composición, así que cómo puedo cargar de manera diferida mis Microfront Ends dentro de la UI, y enrutamiento en el primer nivel de enrutamiento. Te mostraré en un segundo a qué me refiero con eso.

Después de eso, comienzas a construir tus Microfront Ends. La implementación más común que he visto en local o en la nube es esta. Cada equipo está construyendo sus propios Microfront Ends, envían archivos estáticos a un almacenamiento de objetos, posiblemente no contenedores, por favor, por muchas razones, pero en almacenamientos de objetos están absolutamente bien, o almacenamiento de blobs, donde pones tus archivos estáticos, pones el CDN delante de él, y el application shell simplemente está extrayendo estos archivos estáticos de allí. El CDN juega un papel fantástico aquí, porque no es solo para análisis estático, para activos estáticos, sino también para seguridad, enrutamiento, etc. Del lado del cliente, muy simple, no hay ciencia espacial detrás de eso. La renderización del lado del servidor es mucho más complicada.

Una vez más, en este caso, tenemos el application shell que vive en su lugar en el servidor. Cuando el navegador solicita tu sitio web, el CDN pasa a través del clúster específico de contenedores o funciones serverless, y en este caso, básicamente enrutas a través del CDN, por lo que tienes múltiples orígenes que están golpeando diferentes endpoints. Podría ser slash home, slash products, slash my account. Sorpresa, sorpresa, estos pueden parecerse a la estructura de tus equipos o dominios dentro de tu aplicación. Y por lo tanto, tengo un equipo que se dedica a renderizar el home, los productos, etc. El application shell aquí está integrado junto con el propio Microfront End. La belleza de esto es que puedo cachear cada endpoint de diferentes maneras. Puedo decidir que el home debería tener un TTL de tiempo de vida en el CDN de 10 segundos. Al menos absorbe un poco de tráfico. Pero mi cuenta o checkout podría ser más largo, porque es muy estable, no cambia muy a menudo. Esta es una técnica que uso mucho. Por ejemplo, sitios web que probablemente hayas escuchado, formula1.com está construido de esta manera. La renderización del lado del servidor también puede estar en el siguiente paso, donde tengo un UI composer que vive dentro de un contenedor, como slash home, y tengo un montón de archivos estáticos que se cargan de vez en cuando.

Muy común en grandes e-commerces que han trabajado en el pasado, y esos son absolutamente una gran manera de manejar más complicado, pero definitivamente te permite tener un ciclo de retroalimentación rápido para los desarrolladores cuando quieres lanzar en producción. Así que cuando decides cuál quieres seguir, comienzas a enfocarte en el primer micrófono. Así que comienzas con el application shell y tienes algunas heurísticas. Las heurísticas son fantásticas maneras o mecanismos para tener una estrella del norte a seguir, para evitar arruinar grandes tiempos en sistemas distribuidos. Así que en este caso, tu application shell debería ser tecnológicamente agnóstico, potencialmente. Obviamente, a veces quieres usar React de extremo a extremo, pero ten en cuenta que tendrás algunas dificultades cuando necesites actualizar a una versión principal a través de múltiples profundidades de micrófono y el application shell. Te encargas del enrutamiento solo en el primer nivel. Te encargas de la carga diferida con tu framework favorito, single SPA, multi-federation, lo que sea. La mayoría de las veces, si diseñas un application shell adecuado, debería ser estable muy rápidamente. En cuestión de unos pocos meses, es muy poco probable que vayas a tocarlo muy a menudo. Y finalmente, se encarga de la configuración inicial.

Segundo paso, comienzas a construir el primer micrófono, luego no todos ellos, el primer micrófono luego de extremo a extremo. Así que comienzas a diseñar, desarrollar, probar, desplegar, observar. La observabilidad es obligatoria. No es, ya sabes, no quieres despertarte a las 3 de la mañana del sábado porque alguien más ha arruinado algo. Quieres saber qué equipo es responsable de un micrófono específico y asegurarte de que está a cargo de ese micrófono de extremo a extremo. Así que ahora el problema es simple. Tenemos el primer micrófono hecho. Bien, application shell hecho, micrófono hecho. Este es el nuevo catálogo. Pero tenemos el monolito donde el 100% del tráfico está allí. Lo que quieres hacer es generar valor para tu negocio y para tu empresa y para ti mismo también. Están arriesgando el hecho de que estás trabajando durante dos años reescribiendo todo y no teniendo nada en producción. Así que en este caso, lo que haces es comenzar a pensar, bien, ¿cómo puedo moverme con una migración iterativa? Esto lo hemos hecho en el back end con microservicios durante años. Así que no entiendo por qué no lo estamos haciendo para los micrófonos. Así que dijimos que los CDN son poderosos y toda la arquitectura que comparto contigo, tengo un CDN delante de eso por una razón simple. Los CDN no están solo allí para el almacenamiento en caché. También te permiten seguridad y también tienes edge compute. Y edge compute es fantástico porque cuando estás accediendo a un sitio web o cargando un sitio web, pasas a través de un CDN. Por lo tanto, puedo añadir un poco de latencia, unos pocos milisegundos, que me permite enrutar la solicitud a donde quiera.

Así que puedo decir, perfecto, si hay una solicitud de catálogo en el endpoint, llamaré a la parte de microphone tends. Serviré el application shell con el primer microphone tends. Todo lo demás estaría en el monolito. ¿Cuál es el beneficio de eso? Es que si necesito más tarde hacer un rollback, lo único que necesito cambiar es el edge compute. No tengo que tocar el código en nada más. Eso empieza a ser muy atractivo, ¿verdad? Porque incluso cuando estoy trabajando en una gran organización en aplicaciones muy sensibles, no vamos a tener ningún problema al hacer eso.

Pero también puedo hacer más. Una cosa que en microservicios uso mucho es el concepto de canary releases o despliegue bluegreen. Lo que puedo hacer en el edge, hoy en día muchos de los CDNs tienen un almacén de clave-valor disponible en el edge. Así que puedo instruir que cada vez que lancen mis microphone tends, quiero que solo el 10% del tráfico vaya allí. Así que hay incluso más allá el problema. Y el resto, el 90% del tráfico va al catálogo heredado. No tengo que hacer, como ahora, un despliegue big bang cada vez. No entiendo por qué no estamos resolviendo este problema en el front end. Este es un problema ya resuelto en varias otras áreas de computación.

Así que este es un enfoque muy simple. La belleza de esto es que también puedo establecer algunos parámetros. 10% del tráfico, solo en Suiza, solo en Chrome. Esto es algo que hice en 2017. Y lo que he visto es que pasamos de cuatro despliegues por mes a 25 por equipo. Significa cientos de despliegues por mes con datos reales que fluyen de los usuarios a tus equipos. La estrategia de rollback es trivial. Oh, hay un problema. No es un gran problema. Solo cambiamos en un punto de datos dentro del almacén de clave-valor y de repente todo el tráfico vuelve a mi sistema. Solo necesito tener observabilidad disponible para tomar esa decisión. Este es el primer micro frontend. No hay ciencia espacial aquí. Como has visto, ni siquiera toqué el código porque en realidad, ya sabes cómo codificarlo. El problema es cómo vas a crear toda la arquitectura para usar y aprovechar los micro frontends adecuadamente.

Ahora el segundo es interesante. Hay algunas cosas en las que necesitamos pensar. Ahora necesitamos movernos de un micro frontend a otro, pero necesito compartir algunos datos. ¿Cómo puedo compartirlos? Hay diferentes enfoques, obviamente, diferentes técnicas que puedes usar. He enumerado algunas de ellas aquí. Query strings, cookie, local session storage, back-end API. ¿Cuál debería usar? Si tienes datos efímeros, como en este ejemplo, me muevo, tal vez tengo, como, un catálogo con todos los productos, y luego hago clic en un producto específico, y luego paso a otro micro frontend, el ID puede pasarse en un query string. Es accesible a través de JavaScript desde cualquier nivel que tengas. Es una API global a la que puedes acceder muy fácilmente. Es solo por convención, dices buscar dentro del ID. Si es un deep link, lo mismo funcionará como un char, no hay problema en absoluto. Si necesitas tener autenticación, cookies es la forma favorita de manejar eso porque te permitirá incluso delimitar la cantidad de subdominios que puedes usar porque la cookie puedes decir www.preprod.mysite.com tiene acceso a esta cookie, o los otros no. Así que tienes un alcance muy bueno. Mientras que el local y special storage son geniales para datos que pueden vivir dentro del navegador, y listo. Back-end APIs se usa generalmente cuando quieres almacenar algunas preferencias. Tal vez tienes un dashboard para observabilidad que estás construyendo, y tienes múltiples widgets, y creo como usuario una configuración específica de mis widgets para poder almacenarlos allí.

Y luego entramos en la parte interesante. Estado global. Este es el mayor problema de todos cuando construyes micro-frontends. ¿Deberíamos usar un estado global cuando tengo múltiples micro-frontends en la misma vista? Esa es la respuesta. Tenemos un problema, chicos, aquí. La comunicación debe estar débilmente acoplada. Lo que queremos tener es una forma que me permita comunicarme entre micro-frontends pero sin crear acoplamiento. Y por lo tanto, si reflejo estas cosas en el back-end, la mayoría de las veces, lo que piensas es en comunicación asíncrona y termina en mensajería. Podría ser un mensaje, podría ser un evento, podría ser lo que sea. En el front-end, lo que estamos reflejando estas cosas es eventos personalizados, event emitter, o reactive streams. Entre los tres, el más utilizado que he visto son los eventos personalizados. Raramente reactive streams. Pero lo que sugiero es event emitter porque los eventos personalizados están limitados a tu DOM. La posición de tu micro-frontend específico dentro del DOM importa.

Si alguien intercepta ese evento que está burbujeando a window y añade, accidentalmente o no, prevent event default, tu evento se pierde. Nunca llegará a los otros micro-frontends. Con event emitter, solo me suscribo a algo que me interesa. El event emitter no se preocupa dónde colocas tu micro-frontend. Así que no hay razón para no usar eventos personalizados. Event emitter es extremadamente simple y te permitirá tener eventos tipados si quieres sin ningún problema. Porque todo se reduce a este concepto que a menudo olvidamos, encapsulación.

Muy a menudo cuando pensamos en encapsulación, no pensamos inmediatamente que los métodos y los datos necesitan vivir dentro del mismo artefacto enviable. Porque si no, estás filtrando tu dominio fuera y luego creas acoplamiento. Lo último que quiero compartir contigo es el enrutamiento global versus local. Ese es otro concepto importante de los micro-frontends. Así que un enrutador global generalmente se enfoca en el primer nivel de URL. Así que slash home slash catalog. Ese es el papel de la aplicación shell. Eso es lo único que la aplicación shell debería saber. Porque si empiezas a proporcionar más, digamos, cardinalidad dentro de esa URL, entonces básicamente estás filtrando el dominio a una aplicación shell y te encuentras desplegando el micro-frontend y la aplicación shell cada vez. Esa no es la forma en que debería funcionar.

Lo que quieres tener es enrutamiento local. Cuando cargo catalog, todo lo que está dentro de catalog, tengo diferentes categorías, muebles, espejos, mesas, lo que sea, podré mantener dentro del micro-frontend, evolucionando de la manera que quiero como equipo, reduciendo la dependencia externa en enviar tantas veces como quiera. Así es como usualmente diseñas esta parte. Todas esas, digamos, ideas y conceptos, los capturo en este ejemplo usando module federation. Que básicamente está disponible en GitHub. Es completamente, puedes descargarlo, puedes empezar a jugar con eso. Usualmente es module federation también. Obviamente lo mismo podría hacerse con cualquier framework que quieras. Solo elijo module federation porque en este momento he visto un aumento de solicitudes alrededor de module federation, así que trato de abordar eso primero. La pregunta es, ¿puede la IA ayudarnos? Me tomó nueve meses obtener una respuesta adecuada porque no estaba completamente seguro de hasta dónde podía llegar con eso. ¿Cuántos de ustedes han oído hablar de harness engineering? Algunos de ustedes. La idea es muy simple. Hasta ahora hablamos de prompt engineering, context engineering, pero todo se reduce a proporcionar especificaciones al asistente de código y eso es todo.

De repente descubrimos que no es exactamente el código que querían tener. En esta investigación de Birgitta Böckler, que es una ingeniera distinguida en ThoughtWorks, existe esta idea que he estado fomentando por un tiempo de guías y sensores. Necesito proporcionar mecanismos de retroalimentación, como información sobre cómo deberías construir tu micro front end, cómo deberías codificar tu contexto, etcétera, pero al mismo tiempo quiero proporcionar sensores, linters, análisis estático, pruebas de arquitectura, funciones de aptitud que permitan restringir a la bestia, que es nuestro asistente de código, para proporcionar el código que queremos, no el código que él quiere o piensa que queremos.

Por lo tanto, hoy también quiero anunciar habilidades de micro front end. Esto es, digamos, intentar recopilar todo el trabajo que han hecho en los últimos 10 años respecto a cómo diseñar límites, que es de lejos la parte más difícil. Una vez más, es de código abierto, está disponible en GitHub y te permite, si lo pones dentro del proyecto, diseñar micro front ends adecuados. También hay una comparación que he hecho usando eso sin y no usando habilidades de micro front end y mostrando la diferencia en los problemas clásicos que he visto una y otra y otra vez. Así que, con suerte, no tendré que tener una llamada con tu empresa.

En resumen, los micro front ends no son una bala de plata, pero pueden ayudar mucho en situaciones específicas, incluyendo cuando tienes, digamos, múltiples equipos o eres una empresa SaaS que tiene múltiples clientes y quieres tener una parte de tu sistema que quiera ser actualizada más regularmente y otras no. He visto implementaciones exitosas de micro front ends en un amplio espectro de empresas, desde 15 personas hasta cientos de personas. El contexto es clave, y aún más con la IA, porque lo que actualmente se supone que debemos entender aún más, considerando que tenemos tiempo, no tenemos que escribir todo el código, solo necesitamos revisarlo, es acercarse al producto, acercarse al negocio, acercarse a lo que realmente necesitamos expresar. Por lo tanto, diseñar un software no debería ser un lujo más, debería ser tu día a día.

Y quiero cerrar con una de mis frases favoritas en software. Haz crecer tu software, no lo construyas. Esto es de Frederick Rook, uno de los padres de la informática. La razón es porque si tienes la mentalidad de que estás haciendo crecer un sistema, significa que lo estás cuidando, estás trabajando con él, no estás construyendo un sistema. Construyo una casa y la dejo allí. Hago crecer un kit. Esa es la mentalidad que necesitamos tener. Gracias por tenerme, espero que hayan disfrutado la sesión.

Así que creo que tal vez entraremos en la logística del código porque creo que algunas personas están incluso en el camino de, aún no han hecho un micro front-end, tengo un monolito, pero luego la logística de un mono-repo. Así que supongo que es probable que puedas usar un mono-repo con múltiples micro front-ends dentro de él, pero ¿puedes tal vez hablar sobre la logística de cómo gestionas todos estos micro front-ends en tu organización? Así que he visto una implementación exitosa de micro front-ends en mono-repos y poli-repos. No creo que la estrategia de repos cambie el resultado. La realidad es que solo estás definiendo cómo sería tu cultura de ingeniería.

Con un mono-repo, básicamente estás permitiendo que todos vean lo que otros están haciendo. Si tienes ingenieros senior que son capaces de entender que no deberían empezar a tomar atajos en micro front-ends y compartir cosas entre micro front-ends, entonces estás en buena forma. También tienes la posibilidad de usar eso para tener un descubrimiento más rápido y que las personas se integren mucho más rápido. Por otro lado, básicamente obligas a las personas a trabajar por contratos. Eso es usualmente algo que quieres tener porque en un poli-repo, la capacidad de descubrimiento no es tan fluida como en un mono-repo y por lo tanto si quiero hablar con tu equipo, podría necesitar preguntarte, ¿cómo puedo interactuar contigo?

Eso tiene sentido. Parece que muchas de las soluciones son simplemente soluciones organizacionales como la comunicación y lograr que los equipos hablen. Creo que esto está ligeramente relacionado, pero ¿son los micro front-ends una buena idea en la era de los agentes de codificación? ¿No sería mejor un único repositorio para que un agente trabaje en lugar de múltiples componentes independientes ubicados en diferentes repositorios? Creo que es gracioso que puedas reemplazar la palabra agente de codificación por desarrollador. Es solo alguien más que tiene acceso a la base de código. ¿Crees que en el caso de los agentes, es mejor un mono-repo o un único repo? Una vez más, definitivamente el mono-repo para agentes es mucho más útil porque pueden escanear mejor que nosotros y puedes crear algunas guías para evitar trampas. Diría que en este momento recomendaría más los mono-repos que los poli-repos para agentes si delegas la codificación en ellos.

Eso tiene sentido. Esta siguiente es, ¿cómo dejamos claro a la gestión que la reutilización no es siempre el objetivo final o que es más un objetivo a un nivel diferente del componente o del ecosistema del sistema de diseño? Ese es un buen desafío. Usualmente, cuando hablas con directores, VPs, o C-suites, lo que entienden mejor que la parte técnica es su billetera. Así que si tocas su billetera y explicas cuál es el verdadero beneficio de hacer estas cosas en lugar de decir algo como, oh, necesitamos pensar en usabilidad, accesibilidad y cosas así, di, sabes, hay regulaciones que nos obligan a hacer eso. De lo contrario, vamos a tener una multa de X cantidad de millones.

Esto es algo que en mi experiencia usualmente funciona bastante bien. Eso tiene sentido. Cambia la conversación. Se trata del dinero, definitivamente. Quiero decir, esto es un poco crujiente, pero ¿en qué situaciones recomiendas no pasar a micro-frontends? Si eres un equipo pequeño y recién estás comenzando y tienes, digamos, un proyecto que tal vez quieras encontrar el ajuste al mercado, ve con el monolito. Hay frameworks increíbles hoy en día, si pienso en Next, Astro, y Quik o muchos otros que te están proporcionando una herramienta extremadamente increíble para crear muy rápido y expresarte muy rápido en lo que quieres tener. Y puedes probar el mercado rápidamente.

Y puedes probar el mercado rápidamente. Los micro-frontends se utilizan, especialmente en empresas, porque empiezas a tener múltiples equipos, ya sea dentro de la organización o fuera de la organización, que necesitan contribuir en la misma base de código. El cuello de botella cuando tienes un monolito que tiene todo tu código es que puedes incluir tantos desarrolladores en eso o tantos agentes. Pero luego, en algún momento, necesitas lidiar con la complejidad de manejar una gran base de código con millones de líneas de código. Es mucho más fácil dividir un millón de líneas de código en múltiples artefactos que son tal vez 10,000 códigos cada uno, porque es más fácil para nuestra carga cognitiva y también más fácil de mantener a largo plazo.

Me gusta. Es como dejar que la estructura de tu organización coincida con la estructura de tu código o cómo decides construir esto. La estructura de comunicación, sí. Eso tiene sentido. La siguiente, están pidiendo algunos consejos. Entonces, ¿cuáles son los consejos para crear un modelo de dominio compartido escalable si tu modelo de dominio es de una gran organización empresarial? Eso, depende. Creo que necesitamos reevaluar qué se comparte, porque muy a menudo lo que he visto en muchas implementaciones, especialmente en Microfrontend, pero también en el backend, la gente tiende a pensar que lo que debe compartirse es enorme. Pero la realidad es que realmente necesitas entender qué es valioso en todo el sistema.

Así que el análisis que necesitas hacer es bastante amplio en general para entender qué realmente necesitamos compartir entre todos los equipos y qué debe compartirse entre pequeñas cantidades de equipos. Y cuando es una pequeña cantidad de equipos, entonces no tienes que compartir globalmente, porque va a crear más daño que cualquier otra cosa. Cuando tienes una API por ahí que básicamente todos pueden usar, nunca sabes cómo un desarrollador va a usar esos puntos de datos específicos. Y cuando cambias, si no eres consciente de eso, vas a causar más daños que beneficios porque estás introduciendo un cambio disruptivo.

Y otra cosa de la que nunca hablas es básicamente hacer explotar todo el sistema. Así que es muy importante que seas bastante riguroso en la forma en que estás abordando este tipo de modelado compartido en un sistema distribuido, porque puede ir, digamos, al sur muy rápidamente. Definitivamente.

Esta siguiente pregunta, ¿cómo... Bueno, la perdí. Lo siento. Iremos a esta. ¿Cómo manejas proveedores compartidos como React? ¿Han decidido los micro frontends sus propios paquetes o lo dejan al shell y lidian con actualizaciones de gran impacto? Puedo imaginar tener múltiples versiones de una biblioteca o múltiples versiones de React que podrían entrar en conflicto. ¿Tienes algún consejo para manejar eso? Sí, tienes diferentes opciones. Depende del framework que estés usando. Si usas import maps, tienes la posibilidad de tener ámbitos que básicamente están creando un alcance específico alrededor de micro frontends específicos. Similar con much federation, puedes hacer algo así. En el ejemplo que compartí, puedes encontrar exactamente ese ejemplo donde vas a mi cuenta y tienes dos micro frontends, uno usando React 17, el otro usando React 18, que pueden coexistir y funcionar sin ningún problema. En general, necesitas tener cuidado cuando haces micro frontends en renderizado del lado del servidor porque si no... Hay, digamos, frameworks que no son tan, digamos, manejables. Hay más trabajo que necesitas hacer de tu lado para identificar qué dependencia quieres usar y mantener eso. Pero para el renderizado del lado del cliente, es definitivamente mucho más fácil.

Bien. Esta última pregunta aquí. ¿Hay algún framework que hayas encontrado para la emisión de eventos o bus de datos o intercambio de datos para comunicar entre micro frontends? Mencionaste que es un desafío, como, elegir tu estrategia. ¿Hay algo realmente establecido o algo a lo que tal vez deberíamos recurrir primero? Usualmente, lo que he visto más a menudo son las bibliotecas normales que puedes encontrar en npm para emisores. El desafío allí cuando decides ir con un emisor, por ejemplo, es solo el contrato. Así que la mayoría de las veces, la gente está comenzando a crear, digamos, ya sea un repositorio o una biblioteca donde tienes en TypeScript todos los diferentes eventos, contratos, y la gente puede tener, digamos, sugerencias sobre qué deberían expresar dentro del sistema y tratar de evitar tener un número sobre una cadena o lo que sea porque TypeScript te permite hacer eso. Entiendo.