Diseñando una Migración a Micro-Frontends

Bien, en los últimos 10 años, trabajé incansablemente en descubrir cómo podemos tener una arquitectura que esté distribuida en el frontend. Y créanme, fue un viaje. Así que, pasé tiempo implementando. Pasé tiempo diseñando microfrontends. Pasé mucho tiempo recopilando historias de guerra sobre lo que funcionó, lo que no funcionó, definiendo patrones, antipatróns, 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 movieron hacia microfrontends. Y hoy, quiero compartir con ustedes un camino PAVIMENTADO o un camino dorado que les permitirá hacerlo también. Así que, la mayoría del tiempo, si mi clicker funciona, bien, cuando entro en una sala con un equipo que quiere trabajar con microfrontends, la conversación comienza de esta manera. Hemos visto tu trabajo. Nos gusta. Así que, queremos movernos a microfrontends. Pero ya tenemos un plan. Esta es nuestra aplicación. Y simplemente tomamos todos nuestros componentes, los cargamos remotamente y, oh, trabajo hecho. Mi respuesta suele ser esta.

Así que, buena suerte con eso porque eso no es un microfrontend. ¿Qué es un microfrontend, entonces? Así que, la mayoría del tiempo, hay esta confusión de que los componentes son microfrontends cuando no lo son porque un componente tiene un aspecto de implementación específico. Así que, cuando implementas el componente, como puedes ver aquí desde esta entrada de 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 de los componentes está instruyendo al componente para que se comporte de cierta manera. El microfrontend no funciona de esa manera. En un microfrontend, en cambio, tenemos una huella muy pequeña de propiedades. Básicamente, solo tienes un microfrontend que sabe cómo comportarse en un contexto específico. ¿Por qué eso? Porque la realidad es simple. Así que, 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 interfaz de usuario, ¿verdad? Y el microfrontend no es para eso. El microfrontend 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 desde múltiples equipos y alcanzar miles de desarrollos, miles de despliegues por mes. Así que, comencemos con el viaje de migración. Esto es lo que llamo el camino pavimentado, y la mayoría de las veces, la gente comienza desde aquí. ¿Debería elegir como 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. Así que, usualmente, lo que deberías preguntarte es, ¿qué quieres lograr? Porque los sistemas distribuidos son diferentes.

Así que, para ayudarte con eso, pasé los últimos nueve meses trabajando en el lienzo de Microfrontend. Ayer, lo anuncié por primera vez, y hoy, lo muestro por primera vez en un escenario. Este lienzo de Microfrontend 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 un límite de un sistema. Esto está diseñado exactamente para Microfrontend. 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 también en una masterclass con tus equipos. Básicamente, se enfoca en los aspectos clave de cómo diseñas un límite de un Microfrontend. ¿Cuáles son los límites de validación? ¿Cuáles son las restricciones organizacionales? ¿Cuáles son las dependencias, dependencias externas específicamente? ¿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 te describe cómo usarlo. El segundo paso es usualmente entender cuáles son las arquitecturas de Microfrontend más comunes. Así que, las recopilé para ti, para que no tengas que hacer ese trabajo. Usualmente, la mayoría de las veces, ya sea que hagas Microfrontend en renderizado del lado del servidor o renderizado del lado del cliente, comienzas con un shell de aplicación o un compositor de UI. Las responsabilidades de esta pieza de arquitectura son muy simples. Cargas el sitio web. Es lo primero que se carga, ya sea en el servidor o en el cliente. Maneja la configuración, así que encontrar alguna información como en qué dispositivo estás renderizando, por ejemplo, el país donde el usuario está y cosas así. Tienes autenticación, autorización, manejadas de manera centralizada dentro del shell de aplicación, composición, así que cómo puedo cargar de manera diferida mi Microfrontend 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 Microfrontends. Así que, la implementación más común que he visto en prem o en la nube es esta. Cada equipo está construyendo su propio Microfrontend.

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 shell de la aplicación simplemente extrae 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 de cohetes detrás de eso. El renderizado del lado del servidor es mucho más complicado. Entonces, una vez más, en este caso, tenemos el shell de la aplicación que vive en su lugar en el servidor. Entonces, cuando el navegador solicita tu sitio web, el CDN está pasando a través del clúster específico de contenedores o funciones sin servidor, 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 puntos finales. Podría ser barra inicio, barra productos, barra mi cuenta.

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 inicio, los productos, etc. El shell de la aplicación aquí se hornea junto con el propio microfrontend. La belleza de esto es que puedo almacenar en caché cada punto final de diferentes maneras. Puedo decidir que el inicio 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 el pago podrían ser más largos porque es muy, digamos, estable. No cambia muy a menudo. Esta es una técnica que uso mucho. Por ejemplo, un sitio web del que probablemente hayas oído hablar, formula1.

Por ejemplo, un sitio web del que probablemente hayas oído hablar, formula1.com, está construido de esta manera. El renderizado del lado del servidor también puede ser el siguiente paso, donde tengo un compositor de UI que está viviendo dentro de un contenedor, como barra inicio, y tengo un montón de archivos estáticos que se cargan de vez en cuando. Muy común en grandes e-commerces en los que trabajé 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. Cuando decides cuál quieres seguir, comienzas a enfocarte en el primer tiempo de micrófono. Comienzas con el shell de la aplicación y tienes algunas heurísticas. Las heurísticas son formas o mecanismos fantásticos para tener una estrella del norte a seguir para evitar cometer grandes errores en sistemas distribuidos. En este caso, tu shell de aplicación debería ser potencialmente agnóstico a la tecnología.

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 shell de la aplicación. Te encargas del enrutamiento del primer nivel solamente. Te encargas de la carga diferida con tu marco favorito, single SPA, module federation, lo que sea. La mayoría de las veces, si diseñas un shell de aplicación adecuado, debería ser estable muy rápidamente. En cuestión de unos pocos meses, es muy poco probable que lo toques muy a menudo. Y finalmente, se encarga de la configuración inicial.

Segundo paso, comienzas a construir el primer micrófono, no todos ellos, el primer micrófono 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 un sábado por la noche porque alguien más ha cometido un error. 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, ¿de acuerdo? Shell de aplicación 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 backend 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 comparten contigo tiene 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. Y por lo tanto, puedo añadir un poco de latencia, unos pocos milisegundos, que me permite enrutar la solicitud como quiera. Así que puedo decir, perfecto, quiero, si hay una solicitud de catálogo en el endpoint, llamaré a la parte de micro frontends y serviré el shell de la aplicación con los primeros micro frontends. Todo lo demás estará en el monolito. ¿Cuál es el beneficio de eso? Es que si necesito, más adelante te mostraré cómo retroceder 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 grandes organizaciones 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 lanzamientos canarios o despliegue blue-green. Lo que puedo hacer en el edge, hoy en día muchos de los CDNs tienen un almacenamiento de clave-valor disponible en el edge. Así que puedo instruir que cada vez que lancen mis micro frontends, quiero solo tener el 10% del tráfico yendo allí. Así que puedo arriesgar aún más el problema. Y el resto, el 90% del tráfico va al catálogo heredado. No tengo que hacer, como ahora, un despliegue de big bang cada vez. No entiendo por qué no estamos resolviendo este problema en el frontend. 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, el 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 retroceso es trivial. Oh, hay un problema. No es un gran problema. Solo cambiamos un punto de datos dentro del almacenamiento 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 de cohetes 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 que necesitamos considerar. Bien, ahora necesitamos movernos de un microfrontend 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í.

Cadenas de consulta, cookies, almacenamiento de sesión local, API de backend, ¿cuál debería usar? Si tienes datos efímeros, como en este ejemplo, me muevo, tal vez tengo un catálogo con todos los productos y luego hago clic en un producto específico y luego paso a otro microfrontend. El ID puede pasarse en una cadena de consulta. 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 que dices, busca dentro del ID.

Si es un enlace profundo, lo mismo funcionará de maravilla. No hay problema en absoluto. Si necesitas tener autenticación, las cookies son la forma favorita de manejar eso porque te permitirá incluso delimitar la cantidad de subdominios que puedes usar porque la cookie puede decir que www y preprod.mysite.com tienen acceso a esta cookie, todos los demás no. Así que tienes un alcance muy bueno. Mientras que el almacenamiento local y de sesión son excelentes para datos que pueden vivir dentro del navegador, y listo. Las APIs de backend se usan generalmente cuando quieres almacenar algunas preferencias. Tal vez tienes un panel de observabilidad que estás construyendo y tienes múltiples widgets y yo creo, como usuario, una configuración específica de mis widgets para poder almacenarlos allí.

Luego entramos en la parte interesante. Estado global. Este es el mayor problema de todos cuando construyes microfrontends. ¿Deberíamos usar un estado global cuando tengo múltiples microfrontends en la misma vista? Esa es la respuesta. Tenemos un problema, chicos, aquí. Así que la comunicación debería estar débilmente acoplada. Lo que queremos tener es una forma que me permita comunicarme entre microfrontends pero sin crear acoplamiento. Por lo tanto, si reflejo estas cosas en el backend, 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 frontend, lo que estamos reflejando estas cosas son eventos personalizados, emisor de eventos o flujos reactivos. Entre los tres, el más utilizado que he visto son los eventos personalizados, raramente flujos reactivos. Pero lo que sugiero es el emisor de eventos porque los eventos personalizados están ligados a tu DOM. La forma en que la posición de tu específico microfrontend dentro del DOM importa.

Si alguien intercepta ese evento que está burbujeando a window y añade, accidentalmente o no, prevent even default, tu evento se pierde. Nunca alcanzaremos los otros microfrontends. Con event emitter, solo me suscribo a algo que me interesa. El event emitter no se preocupa dónde colocas tus microfrontends. No hay razón para no usar eventos personalizados. Event emitter es extremadamente simple y te permitirá tener un evento tipado si lo deseas 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 afuera y entonces creas acoplamiento. Lo último que quiero compartir contigo es el enrutamiento global versus local. Ese es otro concepto importante de los microfrontends. Un enrutador global generalmente se enfoca en el primer nivel de URL, así que slash home, slash catalog. Ese es el papel del application shell. Eso es lo único que el application shell debería conocer. Porque entonces, si empiezas a proporcionar más, digamos, cardinalidad dentro de esa URL, básicamente estás filtrando el dominio a un application shell y te encuentras desplegando el microfrontend y el application 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 como diferentes categorías, muebles, espejos, mesas, lo que sea. Podré mantener dentro del microfrontend evolucionando de la manera que quiero como equipo reduciendo la dependencia externa y enviar tantas veces como quiera. Así es como usualmente diseñas esto para esta parte. Todas esas, digamos, ideas y conceptos, los capturé en este ejemplo usando module federation que básicamente está disponible en GitHub. Puedes descargarlo, puedes empezar a jugar con eso. Usualmente es module federation 2. Obviamente, lo mismo exacto 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ó como 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, hemos hablado de prompt engineering, context engineering, pero todo se reduce a que proporciono 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 frontend, cómo deberías codificar tu contexto y así sucesivamente, pero al mismo tiempo, quiero proporcionar sensores, linters, análisis estático, pruebas de arquitectura, funciones de aptitud, que permiten restringir, básicamente, 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 frontend. Así que, esto es, digamos, intentar recopilar todo el trabajo que han hecho en los últimos 10 años sobre cómo diseñar límites. Esa 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 frontends adecuados.

También hay una comparación que han hecho usando eso sin y no usando habilidades de micro frontend y mostrando la diferencia en los problemas clásicos que han visto una y otra vez. Así que, con suerte, no tengo que tener una llamada con tu empresa. En resumen, los micro frontends 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 deseas que se actualice más regularmente. Otros no. He visto implementar con éxito micro frontends en un amplio espectro de empresas, desde 15 personas hasta cientos de personas.

El contexto es clave, y más aún 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 acercarnos al producto, acercarnos al negocio, acercarnos 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 nutriendo, estás trabajando con eso, no estás construyendo un sistema. Construyo una casa y la dejo allí. Hago crecer un niño. 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 no haber hecho un micro frontend aún, 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 frontends dentro de él, pero ¿puedes hablar tal vez sobre la logística de cómo gestionas todos estos micro frontends en tu organización? He visto una implementación exitosa de micro frontends en mono repos y poly repos. No creo que la estrategia de repositorio 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. Y si tienes, digamos, ingenieros senior que son capaces de entender que no deberían empezar a cortar esquinas en micro frontends y compartir cosas entre micro frontends, entonces estás en buena forma. También tienes la posibilidad de usar eso para tener, digamos, un descubrimiento más rápido y que las personas se integren mucho más rápido. Por otro lado, básicamente fuerzas a las personas a trabajar por contratos. Eso es usualmente algo que quieres tener porque en un poly 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, ok, ¿cómo puedo interactuar contigo? Y tal vez por diseño, algo que quieras tener dentro de tu sistema. 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 frontends 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 podrías reemplazar la palabra agente de codificación con desarrollador. Es solo alguien más que tiene acceso a la base de código. Entonces, ¿crees que en el caso de los agentes, es mejor un mono repo o un único repo?

Una vez más, definitivamente un mono repo para agentes es mucho más útil porque pueden escanear mejor que nosotros y puedes crear algunas barreras para evitar trampas. Así que diría que en este momento, recomendaría más los mono repos que los poly repos para agentes si básicamente delegas la codificación a ellos. Eso tiene sentido.

Muy bien. Esta siguiente es cómo hacemos claro para la gestión que la reutilización no siempre es el objetivo final o que es más un objetivo a un nivel diferente del ecosistema de componentes o 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 la ganancia real 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 Kruncherian, pero ¿en qué situaciones recomiendas no moverse a micro-frontends? Si eres un equipo pequeño y estás comenzando y tienes, digamos, un proyecto que tal vez quieras encontrar el ajuste del mercado, ve con el monolito. Hay frameworks increíbles hoy en día, si pienso en Next, Astro y Kwik 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. Puedes probar el mercado rápidamente. Los micro-frontends se utilizan, especialmente en empresas, porque comienzas 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 exprimir a muchos desarrolladores en eso o a muchos 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. Es como, deja que la estructura de tu organización coincida con la estructura de tu código o cómo decides construir estos.

La estructura de comunicación, sí. Eso tiene sentido. La siguiente, están pidiendo algunos consejos. ¿Cuáles son los consejos para crear un modelo de dominio compartido escalable si tu modelo de dominio es de una organización empresarial grande? Depende. Creo que necesitamos reevaluar qué se comparte, porque muy a menudo lo que he visto en muchas implementaciones, especialmente en Microsoft Teams pero también en el back end, la gente tiende a pensar que lo que debería compartirse es enorme. Pero la realidad es que realmente necesitas entender qué es valioso en todo el sistema. Entonces, el análisis que necesitas hacer es bastante grande en general para entender qué realmente necesitamos compartir entre todos los equipos y qué debería compartirse entre una pequeña cantidad de equipos. Y cuando es una pequeña cantidad de equipos, entonces no tienes que compartir globalmente porque va a crear más R 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 ese punto de datos específico. Y cuando cambias, si no estás al tanto de eso, vas a causar más R's que beneficios, porque estás introduciendo un cambio disruptivo. Y otra cosa que nunca discutiste es básicamente hacer explotar todo el sistema. Así que es muy importante que seas bastante religioso 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 los proveedores compartidos como React? ¿Han decidido los Microfrontends sus propios paquetes o lo dejan al shell y lidian con actualizaciones de gran impacto? Podría imaginar tener múltiples versiones de una biblioteca o múltiples versiones de React podría causar conflictos. Entonces, ¿tienes algún consejo para manejar eso? Sí.

Entonces, tienes diferentes opciones. Depende del framework que estés usando. Si usas import maps, tienes la posibilidad de tener scopes que básicamente están creando un scope creep alrededor de un Microfrontend específico. Similar con MojFederation, puedes hacer algo como eso. En el ejemplo que compartí, puedes encontrar exactamente ese ejemplo donde vas a mi cuenta que tienes dos Microfrontends, uno usando React 17, el otro usando React 18, que pueden coexistir juntos y pueden funcionar sin ningún problema. En general, necesitas tener cuidado cuando haces Microfrontends en el 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 compartición de datos para comunicar entre Microfrontends? Mencionaste que es un desafío, como elegir tu estrategia. ¿Hay algo realmente establecido o algo a lo que tal vez deberíamos aspirar 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 contratos de eventos. Y la gente puede tener, digamos, sugerencias sobre lo que 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.

Tenemos un poco más de tiempo, así que déjame tomar otra. Sí, ¿cuáles son las preguntas que podemos hacer para determinar si algo es un componente y no un Microfrontend? ¿Cómo manejas componentes inteligentes para una pieza de integración de servicio de UI? ¿Una pieza de integración de servicio de UI? Bien, entonces en ese caso, diría ten cuidado en ese escenario. Si quieres algo muy granular que tenga, digamos, un poco de interacción con el servidor, eso no es un problema. Depende de cuánto se filtre hacia afuera porque si luego el contenedor necesita instruir a este componente inteligente para comportarse de cierta manera, eso no puede ser enviado de manera independiente. Cada vez que cambias el contenido, necesitas enviar el componente inteligente y el contenedor. La belleza de Microfrontend es que estamos evitando eso por diseño para reducir las dependencias externas y acelerar el despliegue para que seas completamente independiente en esa parte. Por eso, en una situación como esa, argumentaría tratar de averiguar si un Microfrontend te conviene mejor que solo un componente inteligente porque podrías arriesgarte a tener muchos componentes inteligentes y mucho acoplamiento ocurriendo en una sola vista y luego no puedes culpar a la arquitectura si eso no funciona. Fantástico. Eso es todo el tiempo que tenemos, pero muchas gracias.