El Lado Oscuro de los Micro-Frontends

En los últimos 10 años, me embarqué en este viaje sobre cómo hacer un sistema distribuido en el front end. Y los últimos cinco, estuve trabajando para AWS, así que tuve el placer de trabajar con cientos de equipos en todo el mundo, equipos internos de Amazon, AWS, equipos de Nueva Zelanda, Silicon Valley, de seguros, bancos, comercio electrónico, lo que sea. Y he visto bastantes, digamos, malas implementaciones de micro-intents y exitosas implementaciones de micro-intents. Y hoy, solo quiero resaltar los principales problemas que he visto con micro-intents. No va a ser una clase sobre cómo funcionan los micro-intents de principio a fin, sino enfocándome en los principales problemas, porque son las partes que generalmente duelen más.

Bien, veamos si funciona. Sí. Bien, la mayoría de las veces cuando entro en una sala con un cliente, hacemos una pequeña sesión de pizarra juntos. Y tal vez ya comenzaron a desplegar algo en producción. Lo que veo es algo así. Tienen un sitio web y luego simplemente dicen, bien, escuchen, ¿pueden explicarme cómo funciona? Y luego les digo, oh sí, por supuesto que podemos. Entonces, tenemos el encabezado, este es un micro-intent. Luego tenemos otro componente, otro micro-intent, otro micro-intent, otro micro-intent, otro micro-intent, y así hasta el final. Ahora, hay un problema fundamental aquí que es básicamente pensar que los componentes y los micro-intents son exactamente lo mismo. Y en segundo lugar, pensar que la composición en tiempo de ejecución es la única forma de hacer micro-intents. Eso no es absolutamente cierto.

Luego pasamos al siguiente paso. Este es el verdadero lado oscuro de los micro-intents, donde después de decirme cuántos componentes tienen o cuántos micro-intents tienen en la misma vista, comienzan a decir, oh sí, porque estamos usando iteración modificada, pero estamos pensando en Single SPA, pero también queremos un poco de Next JS multi-zone, estamos usando un enfoque de múltiples frameworks, o estamos eligiendo uno de esos frameworks, o incluso sin frameworks, estamos usando iframes, lo que sea. El problema es que ninguno de esos está haciendo una plataforma de micro-intents exitosa. Así que, deténganlo. Eso es lo más importante, la única conclusión que deben sacar de esta parte.

Entonces, por favor, tampoco culpes a la arquitectura, como he escuchado un millón de veces, eso no es solo para micro-intents, por cierto, también es para cualquier sistema distribuido, también microservicios, he escuchado varias veces, si las cosas no están funcionando. Porque necesitas pensar en tres dimensiones cuando estás diseñando un sistema distribuido, no es solo para micro-intents. Necesitas pensar en la parte de arquitectura, así que invertir tiempo diseñando tu sistema. Necesitas pensar en la cultura de ingeniería que quieres tener. Si tienes, no sé, la mitad o la mayoría de desarrolladores junior, no puedes comenzar inmediatamente con las cosas más avanzadas que encuentras en ingeniería. Y finalmente, necesitas pensar en la topología del equipo, así que cómo estás estructurando los equipos. Porque cada decisión que tomas en una arquitectura va a afectar, intencionalmente o no, las otras dos dimensiones, y viceversa, por cierto. Así que, cuando ves fricción dentro del sistema, es un regalo. No es negativo, es un regalo. Porque significa que algo no funciona y necesitas entender qué dimensión vas a resolver. ¡Sorpresa! La gran mayoría de las veces no es la arquitectura.

Bien, así que quiero compartir contigo los tres errores más comunes que he visto en los últimos cuatro años y cómo superarlos. El primero es, ¿qué es un micro-intent? No tienes idea de cuántas veces pregunto cuán micro es un micro-intent o cuán micro es un microservicio, por cierto. ¿Son 100 líneas de código un microservicio o un micro-intent? Pero la respuesta es no. Hay diferentes características. Así que intentemos llegar a un consenso sobre esto. Tomemos lo más increíble... No soy diseñador, como puedes ver. Veamos las cosas más increíbles que puedes tener o las cosas más granulares que puedes tener frente a este componente. Así que este botón está exponiendo un montón de propiedades. Así que tienes la etiqueta, tienes métodos, tienes un ID, tienes un montón de cosas. Piensa en eso. ¿Quién está configurando esta información? El contexto del botón, ¿verdad? Así que es el contenedor del botón el que está instruyendo al botón cómo comportarse.

Deberías estar habilitado, deberías estar deshabilitado, deberías ser algo más. Por lo tanto, la lógica del contexto es propiedad del contenedor del botón, no del propio botón. Porque lo que estamos tratando de hacer es algo diferente a un micro-intent. Mientras que un micro-intent, la mayoría de las veces, funciona de esta manera. Tienes un micro-intent, se llama catálogo, y contiene todo lo que se necesita o casi todo. No tienes que inyectar mucho. ¿Por qué eso? Porque todo lo que está dentro del micro-intent entiende exactamente cómo comportarse. No necesita más contexto.

¿Por qué estamos haciendo esto? Porque si piensas en la diferencia entre un componente y un micro-intent, recuerdas que una biblioteca de componentes en un sistema de diseño, o donde sea, está diseñada para reutilización. La reutilización, no lo digo yo, sino alguien más importante que yo, como Neil Ford, es una forma de acoplamiento. Lo que quieres hacer con los componentes es reducir la duplicación y finalmente tener consistencia en la UI. Este es el objetivo de los componentes. Ese no es el objetivo de los micro-intents. Lo que quieres hacer con los micro-intents es optimizar para la independencia. Quiero reducir la dependencia externa, reducir, no eliminar, ya sé que ya estás pensando en silos, reducir las dependencias externas de mis equipos para acelerar y alcanzar el flujo rápido.

Si no conoces el concepto de flujo rápido, te recomiendo encarecidamente que leas el libro Accelerate. Es un libro excepcional que introduce la idea de las métricas Dora y también explica por qué las empresas exitosas operan de cierta manera. Los micro-intents, por lo tanto, son definitivamente diferentes de los componentes. No puedes estructurar las cosas que muestro al principio de la primera diapositiva porque solo hay un desorden distribuido y no micro-intents. Entonces, ¿cómo dividimos, Luca? Si miras, trabajo con muchas empresas, pero incluso en grandes empresas, comienzas con un grano grueso. No comienzas inmediatamente con un grano fino porque el grano grueso es como tener un trozo o un pequeño trozo de tu sistema que se asigna a un equipo y comienzas a trabajar en eso e iterar en eso porque tienes menos complejidad. Es más fácil dividir.

Si te estoy diciendo que tomes tu sitio web, piensa que son cuatro equipos e intenta asignar dominios dentro de esos equipos que sean replicables en una vista o grupo de vistas, podrás hacerlo. Es más rápido construir y desplegar porque los desarrolladores ya saben cómo construir una aplicación de una sola página o una aplicación de renderizado del lado del servidor, pero solo una parte de eso se dedicará a ellos lo suficiente como para no alcanzar una alta carga cognitiva. Además, es más fácil revertir. Vamos a discutir la reversión en un segundo.

Por lo tanto, ¿cuál es la heurística que deberías considerar? Existe este concepto de arquitectura de software que se trata de cuán granular quieres llegar. Esto no es solo para micro-servicios, sino también para otros. Existe esta idea de integradores y desintegradores. Un ejemplo clásico es la volatilidad del código. ¿Con qué frecuencia vas a cambiar? Hay áreas de un sistema que puedes identificar muy fácilmente que requieren un alto esfuerzo al principio, y luego no las tocas nunca más. Que puedes agregar muy fácilmente porque sí, al principio será un poco incómodo, pero no tienes que dividirlo en 25 mil micro-front-ends diferentes porque no te están aportando ningún valor.

Solo está haciendo tu vida más miserable. A veces es la seguridad la que te obliga a hacer eso, una relación de datos o compartir código. Un ejemplo, solo para hacerlo más concreto, piensa en los pagos. Si tienes un micro-servicio de pagos, a veces he visto equipos que comenzaron a tener un micro-front-end para PayPal, un micro-front-end para una tarjeta de crédito, un micro-front-end para tarjeta de regalo, y así sucesivamente. Pero la realidad es que cuando preguntas, ¿con qué frecuencia cambias la tarjeta de crédito y PayPal, aparte de cuando tengo que actualizar la versión del SDK, nada más. Entonces, ¿por qué estás creando múltiples micro-front-ends?

Entonces, ¿por qué estás creando múltiples micro-front-ends? La razón es que necesitas pensar en cómo vas a descomponer intencionalmente tu sistema. No es que simplemente digas al azar, está bien, esto es un componente, esto es un componente, por lo tanto, puedo cargar un tiempo de ejecución porque se disparará muy rápidamente. La otra cosa es que, generalmente con los micro-front-ends, lo que tienes es un application shell. Entonces, lo primero que cargas cuando llamas al sitio web con micro-front-ends es un application shell, si haces renderizado del lado del cliente. De manera similar también en el lado del servidor, pero está viviendo en el servidor.

Y hay algunas reglas aquí, algunas heurísticas que siempre trato de impulsar cuando veo cierta implementación. He visto implementaciones donde el application shell está escrito en Angular, React, Solid, lo que sea. Pero el problema allí es que en realidad el application shell no necesita tener un framework específico, potencialmente. Puedes ser lo más agnóstico posible en cuanto a tecnología. Una buena regla general es, si estoy construyendo un application shell que está cargando, enrutando, componiendo micro-front-ends sobre la marcha, y puedo usar para este proyecto aquí, pero también para los otros proyectos, entonces estás diseñando un muy buen application shell.

¿Por qué eso? Porque quieres tener una versión estable del application shell. El ciclo de vida del application shell para los desarrolladores debería ser una alta tasa de cambio al principio, y luego no deberías tocarlo más. Porque externalizas un par de cosas, como el enrutamiento, el mecanismo de composición siempre será el mismo, solo tendrás una configuración inicial que expones, y eso es todo. Y por lo tanto, si empiezas a mirar en el application shell, como tengo algunos clientes que han hecho eso, donde empiezo a tener lógica de aplicación en el application shell, entonces de repente necesitas desplegar tu micro-front-end con tu application shell.

Y, sorpresa, esto no es un problema de arquitectura. La otra cosa que necesitas considerar es el enrutamiento en el application shell, y necesitas discernir los dos aspectos, enrutamiento global y local. La forma más sencilla de implementar la primera implementación de tu plataforma de micro-front-end es mirando en el primer nivel de URL. Así que mysite.com slash catalog slash my account slash landing page, lo que sea. Ese es el primer nivel de URL. Esa es una buena manera de dividir un micro-front-end. Si lo haces a nivel de enrutamiento, tienes muchos beneficios. Te mostraré en un segundo muchos otros.

Y luego lo que delegas es el enrutamiento local dentro del propio micro-front-end. Es obvio que si comienzas directamente con la división horizontal, como lo llamo, entonces tienes múltiples micro-front-ends en la misma vista, esto se vuelve complicado. Usualmente un patrón que recomiendo cada vez es crear un meta-shell, o básicamente un shell de un shell, que básicamente dedica su existencia a posicionar los micro-front-ends dentro de una vista única. ¿Por qué eso? Porque primero que nada, el application shell es capaz de ser completamente independiente, y solo carga un artefacto, sea lo que sea. Es un meta-shell o un micro-front-end real, no importa. Pero en segundo lugar, los equipos que son responsables de construir estos micro-front-ends independientes, porque la gran mayoría de las veces, hay múltiples equipos trabajando en eso, poseerán ese meta-shell sin interactuar con dependencias externas.

Entre los tres o cuatro equipos que están trabajando en eso, simplificará drásticamente el despliegue y los cambios. Si hacen un buen trabajo, potencialmente pueden hacer alguna optimización interesante, porque tal vez dos micro-front-ends están llamando a la misma API, pero si poseen el meta-shell, pueden delegar al meta-shell para hacer esta parte e inyectar el resultado dentro del micro-front-end. Así que empiezas a ver que hay algunas capacidades que muy a menudo no son consideradas, porque la complejidad de los micro-front-ends no es implementar React o usar una gestión de estado específica. Eso es algo que hacemos día a día. El problema es que estamos volviendo al diseño y no solo seleccionando bibliotecas. Eso es una bestia completamente diferente.

Entonces, cuando tienes enrutamiento local, tienes algo así. Dentro del micro-front-end, si estás usando React Router, tengo un ejemplo que compartiré más tarde, puedes hacer algo así. Simplemente delegas, básicamente, para manejar furniture slash table y tengo un cliente, por ejemplo, hay un e-commerce aquí en el Reino Unido, que el primer micro-front-end que desplegaron junto a su sistema existente fue la categoría espejo de su e-commerce. El resto del e-commerce era monolito. Luego, lenta pero constantemente, cuando aprendieron algunas cosas, tuvieron que retroceder un par de veces porque cometieron algunos errores, pero luego, lenta pero constantemente, comenzaron a desplegar todos los diferentes micro-front-ends, uno tras otro. Aumentaron esto, digamos, espejo uno con no sé, muebles y otras cosas, y lenta pero constantemente, crearon y desplegaron sus micro-front-ends. Esta es una gran estrategia para vender incluso a tu gestión que no necesitas 18, 24 meses de desarrollo oscuro o desarrollo en modo sigiloso para construir un sistema completo. Construyes un micro-front-end, una ruta, iteras sobre eso, y creces con eso. Mientras tanto, que estás haciendo este trabajo de extremo a extremo, aprenderás mucho porque te ves obligado a pasar por todo el proceso desde la ideación, construcción, creación de la observabilidad, registro, despliegue, etc. Súper importante.

Pero también, cuando estás construyendo micro-front-ends, es una parte que muy a menudo se estropea por la gente. Si miras los diferentes ejemplos de single SPA, multi-federation, etc., la mayoría de las veces la gente está escribiendo en los ejemplos todos los diferentes micro-front-ends y remotos para cargar dentro de la configuración de Webpack o RSPack o lo que sea. Eso es un problema. No está listo para producción porque todos aquí están usando un enfoque de multi-entorno Cuando trabajas con un enfoque de multi-entorno, podrías tener entornos efímeros a veces si tienes suerte y no tienes solo tres configuraciones específicas. Incluso si tienes tres configuraciones específicas, es doloroso si, digamos, escribes dentro de la configuración de Webpack antes de que puedas aprovechar el enrutamiento dinámico. ¿Qué significa? Hace cuatro años, creé un grupo de trabajo. Era yo, era Zach Jackson, el creador de multi-federation, era Joel Danning, el creador de single SPA, y luego estaba Mateo Figues, que es el creador de Open Components. Estos tres frameworks son los frameworks más usados en todo el mundo para construir micro-front-ends. Dije, escuchen chicos, necesitamos encontrar una solución para resolver el problema del despliegue y enrutamiento porque tiene que ser algo agnóstico que podamos usar en cada framework. El framework que tenemos hoy, pero el framework que también tendremos mañana. Antes de que llegáramos a este esquema que se hizo disponible en GitHub públicamente. Este esquema básicamente es un esquema de descubrimiento, como lo llamamos, que nos permite tener un montón de información relacionada con los micro-front-ends. Porque es JSON, puede ser generado donde quieras. Puedes tener tu CI, CD, la tarea final que básicamente está generando este esquema o almacenando en una base de datos, donde quieras. Pero lo genial es que un application shell puede cargar esto y directamente desde este esquema generar el enrutamiento dinámico. Así que, puede que un usuario en, digamos, una aplicación específica, tal vez un usuario no necesite cargar el catálogo porque no tiene el permiso y otro sí, pero puedes implementar fácilmente este JSON con un enrutador directo. Así que, simplemente tomas este JSON, lo analizas, recuperas la información que necesitas, y luego generas las rutas dinámicamente. La belleza de eso, si estás usando, en este caso, Moji Federation, lo que puedes hacer es cuando tienes, digamos, un cambio de páginas, puedes cargar de manera diferida aprovechando la API avanzada de Moji Federation sin escribir todo dentro de la configuración para cargar dependencias comunes, así como cargar un micro-front-end específico. Muy simple.

No hay magia aquí. Es extremadamente fácil y básicamente cargará solo un módulo. Esto es lo que con Moji Federation puedes hacer en JavaScript puro. Si quieres usar el ASM, puedes usar single SPA y actualizar e importar mapas. Hay un millón de maneras de hacer eso, pero el concepto es exactamente el mismo.

Y luego, obviamente, tendrás un suspense donde inyectas... Oh, esto es interesante. Hay esta cosa agradable que se llama... Bien, no puedo verlo. Así que, aquí hay un emisor. Esta es usualmente la forma en que te comunicas entre micro-front-ends. Muy a menudo, la gente piensa en el siguiente tema que es el estado global que vamos a discutir en un segundo.

La belleza de este servicio de descubrimiento que llamamos servicio de descubrimiento de frontend es muy simple. Así que, tienes un application shell que está llamando a través de un CDN, un endpoint que es un servicio de descubrimiento de frontend, devuelve el JSON, y has visto la lógica que va a manejar. Y luego, cuando está hecho, puedes comenzar a recuperar los diferentes micro-front-ends ya sea desde, digamos, un endpoint si estás usando renderizado del lado del servidor para los micro-front-ends o si es un JSON estático puedes recuperarlo desde allí.

Pero este es un patrón muy común que han visto implementado con mucho éxito. Y puedo decirte más. Hoy en día, puedes usar el frontend discovery incluso en el borde. Cada proveedor de nube, así como proveedor de CDN, están ofreciendo la capacidad de almacenar algunos datos en el borde así como tener computación en el borde. Y por lo tanto, este tipo de cosas se pueden hacer fácilmente a través de un CDN que no añadirá mucha latencia y será súper eficiente y escalable porque usualmente hay más puntos de presencia de un CDN en comparación con la región dentro de un proveedor de nube.

Por lo tanto, definitivamente algo a considerar. Y por último, pero no menos importante, que es súper genial, puedes comenzar a implementar algo que se llama lanzamientos canarios, un problema resuelto hace 15 años por microservicios. Pero por alguna razón en frontend, olvidamos eso, que si tienes, digamos, la posibilidad de enrutar cosas en el borde, entonces puedes decir, perfecto, despliego un nuevo catálogo. Tengo el 10 por ciento del tráfico yendo allí. Puedo probarlo. Incluso puedo seleccionar porque todos los CDN te permiten seleccionar para recuperar información como la ubicación de la solicitud así como la solicitud del navegador.

Y en mi trabajo anterior antes de unirme a AWS, teníamos una solución ejecutándose en el borde que nos permitía decir, quiero desplegar un micro-frontend solo en Suiza, solo el cinco por ciento del tráfico, solo en Chrome. Y eso permitió, eso movió la aguja en el despliegue, por lo tanto el enfoque de flujo rápido que describía antes, de desplegar dos veces o tres veces por mes a 25 veces por día por equipo. Y ahí es donde quieres estar porque no hay en un sistema distribuido un consejo asesor de cambios que pueda decirte si un cambio te ayudará o no, desafortunadamente. Así que gracias a eso, la estrategia de reversión que mencionaba antes no es, oh, necesito desplegar algo más.

No, necesito cambiar la configuración y automáticamente todo el tráfico vuelve a donde estaba. Y ese es un gran lugar para estar porque creas una red de seguridad para los desarrolladores. Si estás interesado en saber más sobre eso, creé un ejemplo de Moncho Federation donde hay un pequeño e-commerce donde puedes ver aquí la implementación. Esto es con Moncho Federation 2.0. Esta es la última que salió GA hace unos meses.

Bien, así que lo último, estado global. No tienes idea de cuántas veces he escuchado sobre esto. ¿Por qué, Luca, no podemos tener un estado global que podamos orquestar todo? Esto es malo. Esto es realmente malo. He visto un cliente que hizo eso, ha pasado seis meses refactorizando para alejarlo. Porque cuando quieres comunicarte, usualmente usas esta construcción libre. Eventos personalizados, event emitter, flujos reactivos.

Mi mejor sugerencia que puedo darte es usar event emitter donde sea posible, y los flujos reactivos, si estás en una empresa que sabe cómo usar flujos reactivos, te puedo garantizar que no es un paseo por el parque. Escribí un libro sobre este tema, así que conozco muy bien el problema. Luego tienes el intercambio de datos, que es la otra cosa en la que necesitas pensar. La comunicación es una cosa, pero luego también necesitas enviar algunos datos. Usualmente divides en datos importantes y datos efímeros.

Como un id de un producto, puedes usar una query. Pasas esta información para una query, es efímera, no tienes que almacenarla en ningún lugar. Muy fácil de recoger. Por convención, todos recogerán de la cadena de consulta hecha. Pero luego si tienes sesión u otras cosas, puedes usar cookies. Tal vez tienes una personalización de una UI, puedes usar una API de back-end, y así sucesivamente. Ya hay soluciones que están bien hechas, pero necesitas entender cuál es tu contexto.

Necesitas dedicar tiempo a entender qué necesitas expresar. ¿Por qué digo que el estado global no funciona? Porque básicamente estás rompiendo la idea de encapsulación. Sé que muchas personas dicen, oh sí, pero conozco perfectamente todos los patrones. Pero la realidad es que la encapsulación, lo que dice, es que necesitas tener datos y métodos que estén protegidos del resto del mundo. Así que tienes un montón de eventos que están llegando allí. Así es como diseñas verdaderos micro-frontends.

Si empiezas a tener datos que se comparten entre sistemas, es exactamente lo mismo en microservicios. Tienes una base de datos que se comparte entre 10 microservicios. Y luego, ¿qué pasa cuando cambias el esquema de la base de datos? Oh, necesito probar de nuevo, todo, coordinando múltiples equipos, y tal vez están en diferentes zonas horarias, y bla, bla, bla, bla, bla. Eso no es un problema en la arquitectura. Es un mal diseño. Oh, volví en lugar de avanzar. Bien.

Otro enfoque, si no quieres usar, digamos, la división horizontal que es más compleja, es usar BFF. Así que back-end para front-end. Si tienes un solo equipo haciendo el front-end, tienes múltiples, digamos, API que necesitas agregar. No tienes que delegar la UI a los otros equipos. Puedes fácilmente consumir estas APIs en el back-end para front-end donde tienes todos los datos allí. Y cada vez que hay una solicitud, ya sea que obtengas datos frescos o caches los datos, como hemos visto en la charla anterior.

Ahora, el consejo adicional de esta sesión es este. Gobernanza para ganar. Muy a menudo, donde la gente se equivoca es que se olvidan de la gobernanza. En sistemas distribuidos, la única manera de saber qué está pasando es tener gobernanza aplicada, porque de lo contrario, te puedo garantizar, si eres un super desarrollador, arquitecto principal, donde sea, no puedes estar en cada sala todo el tiempo. Por lo tanto, lo que usas son funciones de fitness que son un enfoque arquitectónico para probar tu aplicación. El libro es Building Evolution Architecture, altamente recomendado.

Un ejemplo es el tamaño del presupuesto. ¿Cómo puedo asegurarme de que los microfront ends no tengan un megabyte para cargar? Muy fácilmente. Así que creas, básicamente, cada vez que abres un PR, creas un githook e inmediatamente recuperas, descargas o clonas el proyecto, construyes el proyecto sobre la marcha, como lo hacía en los días pasados en una función lambda, y luego verificas que estaba dentro de un cierto escudo de árbol. Y eso funciona de maravilla, porque puedes detectar inmediatamente si los desarrolladores arruinan la configuración de tree shaking o se olvidan de la biblioteca que están usando.

También puedes probar decisiones arquitectónicas. Si dices en la carpeta de la biblioteca compartida, quiero tener el encabezado y el pie de página y los asientos. Con TS-Arc, puedes probar y decir dentro de esta carpeta, quiero ver x, y, z. Y esta es una prueba que puedes ejecutar cada vez que alguien actualiza esa carpeta específica.

Y finalmente, gestión de dependencias. Muy a menudo, necesitas, tienes un sistema de diseño. Quieres actualizar a través de múltiples microfrontends. Eso es fácil. Se llama dependable. Está ahí desde hace años. Simplemente lo configuras y luego cada noche, incluso si es una biblioteca externa o interna, irá y abrirá un PR por cada cambio que necesites hacer. No tienes que estar presente y la IA puede automatizar todo esto.

Así que, es realmente fácil de implementar siempre y cuando sepas lo que estás haciendo. Por lo tanto, quiero cerrar con probablemente mi cita favorita de Frederick Brooke, uno de los creadores o escritores detrás de There is No Silver Bullet, White Paper, que necesitas hacer crecer tu software.

Eso no es como queremos construir nuestro software. Si disfrutas y quieres profundizar más en micro-frontends, tengo un boletín gratuito que puedes encontrar allí. Y la segunda edición de mi libro está disponible desde la semana pasada en todo el mundo sobre la construcción de micro-frontends. Eso es todo lo que tengo. Espero que lo disfrutes y disfrutes la fiesta.

¿Hay un lado positivo en los micro-frontends? Un lado positivo. Hay un lado oscuro. Hay un lado positivo. El lado positivo es cuando funcionan, donde comienzas a ver, digamos, el negocio que ve el valor real de la implementación. Porque comienzas a desplegar muy a menudo, puedes hacer más pruebas en producción, puedes acelerar las nuevas características que tienen en mente, y cosas así. Así que al final del día, estamos escribiendo código con la idea de generar un valor para nuestros usuarios y nuestra empresa. No es un patio de juegos para desarrolladores. Eso es al menos como yo pienso.

Justo. Definitivamente estoy muy de acuerdo con eso. Creo que muchas veces construimos código para nosotros mismos, y no es como se supone que debemos construirlo para la gente. No es que la calidad del código no importe. Es como que otras cosas a veces importan más, como poder desplegar más rápido, poder iterar, poder enviar características, para ayudar a la gente. Sí. Bien. Ahora, saliéndonos del tema, y no tenemos dos minutos y 48 segundos. ¿Cuándo crees que es una buena idea usar monorepos versus repos separados para micro-frontends? Es increíble porque esta pregunta la tengo al menos una vez en cada charla que doy en los últimos cinco años. Así que ambos funcionan, ambos no funcionan. ¿Y por qué eso? Porque en realidad, lo que estás describiendo en la selección de monorepo y polyrepo es el comportamiento de tus ingenieros. La mayoría de las veces, si piensas en el monorepo, básicamente estás forzando a la gente a usar desarrollo basado en trunk. No todos están acostumbrados a hacer eso correctamente. Y si rompes master, buena suerte. Y si tienes muchas personas junior que no están familiarizadas con tener este bucle de retroalimentación de velocidad rápida, podrías tener más problemas que beneficios. Mientras que si haces polyrepo, lo que básicamente estás, digamos, diseñando es el hecho de que los equipos tienen menos descubribilidad, y los fuerzas a trabajar por contratos.

Eso podría ser lo que quieres, o podría no serlo. Pero creo que he visto, digamos, implementaciones con monorepo moviéndose a polyrepo y viceversa. Y los he visto fallar, y los he visto tener éxito. La realidad es que no es una elección tecnológica. Es cómo quieres que tus ingenieros trabajen juntos y qué cultura de ingenieros quieres dentro de tu sistema.

¿Crees que también es una buena idea a veces tener un poco de ambos? Como cosas que están un poco conectadas están en el mismo repo? Propuse una idea en mi libro hace cinco años que era dominio repo. Sí, exactamente. Algo así. Eso está mucho mejor dicho que lo que yo dije. Exactamente. Entonces, el dominio repo es esta idea de que tienes, digamos, un monorepo, pero tienes, digamos, múltiples dominios. Y por lo tanto, tienes un monorepo por dominio. Me gusta mucho eso. Sí.

Bien. ¿Cómo te sientes acerca de los micro frontends a través de componentes web? Viendo que muchas veces, tengo que decir en los últimos tres años, no muchas personas están usando, aparte de, digamos, aprovechar el shadow root. Esa es una buena manera de encapsular y delimitar el contenido dentro. El problema que tienes con eso, sin embargo, es que si tienes una versión diferente de React, al final del día, estás enviando mucho código que es prácticamente inútil.