Adoptando Micro-Frontends Sin Micro-Frontends

Hoy voy a hablar de adoptar micro frontends sin micro frontends. Ruben, el orador anterior, dio una gran charla y yo solo estaba allí mirando lo que estaba diciendo. Me quedé asombrado, realmente explicó todo. Así que ahora voy a intentar convencerte de cómo tal vez no seguir ese camino hasta el final.

¿Quién soy yo? Alex. Me presentaron. Actualmente trabajo para Miro. Si no conoces Miro, es un frontend muy complejo. Muy desafiante. Es una plataforma de colaboración en tiempo real infinita. Realmente desafiante. Si quieres unirte al desafío, puedes unirte a la empresa. Y hoy, ya que Ruben no te dio la definición, aquí estoy yo. Te la voy a dar. ¿Qué es un microfrontend? Y esta es la definición canónica que encontrarás en cualquier publicación de blog y charla de conferencia que se escribió hace unos años y básicamente dice que es un estilo arquitectónico donde las aplicaciones frontend independientes se componen en un todo mayor.

Entonces, ¿cuál es el punto de los microfrontends? ¿Qué obtienes? El principal beneficio es la escalabilidad empresarial. Y significa que puedes agregar más personas a tu proyecto, y digamos que duplicas el número de personas que trabajan allí, entonces duplicas el resultado. Y lo haces porque son cosas independientes, ¿verdad? Puedes agregar un nuevo flujo, un nuevo flujo de valor, y así sucesivamente, y por eso es escalable. No confundir con, por ejemplo, la plataforma o dónde se ejecuta tu software, porque tu aplicación frontend se ejecutará en algún momento, a menos que no tengas JavaScript, en un navegador, y no podrás escalar ese hilo. Entonces, ¿cuáles son las desventajas? Primero está el rendimiento. Sabes, puedes afectar el rendimiento de dos formas diferentes. Una es tu aplicación. Estás haciendo las cosas muy independientes, por lo que puedes duplicar o no cierto código. Ya sabes, lo clásico. Descargas el mismo framework dos veces. También necesitas ejecutar cosas, algunas cosas puedes ejecutarlas dos veces, y también tal vez solicitar datos dos veces, pero también tus equipos, tal vez porque estás haciendo las cosas, si estás realmente enfocado en hacer las cosas muy independientes, tal vez duplican el trabajo, crean CI pipelines para repositorios muy diferentes, y así sucesivamente. También puedes afectar la consistencia por la misma razón, simplemente haciendo las cosas independientes. Ahora, si lees cualquier artículo, la mayoría de las charlas sobre micro-frontends dicen que no compartas ningún estado. No deberías hacer eso. La razón es porque quieres que las cosas sean independientes, pero si no compartes ese estado, mantienes, si cambias el idioma en un micro-frontend, supongo que quieres cambiar el idioma en el otro, ¿cómo lo sabes? ¿Cómo lo solucionas? Lo mismo con el diseño.

Puedes crear un sistema de diseño, pero también puedes tener diferentes versiones de tu diseño sistema, así. Y luego la confiabilidad. Y con confiabilidad me refiero a que cuando ejecutas algún código, básicamente no debería fallar, ¿verdad? Una vez que el código se ejecuta, debería producir el resultado esperado. Esas son, ya sabes, hay formas de solucionar eso y mejorar esas cosas y mitigar muchas de esas cosas. Rendimiento y consistencia. Pero no es el caso con la confiabilidad.

Permíteme darte un ejemplo. Voy a usar Twitter como ejemplo aquí. Digamos que queremos dividir Twitter en micro frontends. Y así, tenemos esta página que contiene, esta es la página de inicio. Es una página de feed y crearemos un micro frontend para el feed. Cuando haces clic en ese botón, muestra un modelo y podríamos crear otro micro frontend para eso. Es un equipo diferente, un equipo de participación, lo que sea. Es un micro frontend, lo llamaremos micro frontend de respuestas.

Lo que va a suceder es que, en algún momento, tenemos estas dos versiones, todo funciona. Entonces, el usuario va a Twitter, luego el usuario recibe un HTML que dice, oh, necesitas descargar este JavaScript para el feed. Y así, eso está bien, funciona. Se muestra en el navegador. Pero luego en segundo plano, se implementa la versión dos de ese micro frontend. Puedes probar eso, también puedes probar eso, asegurarte de que el recorrido donde el usuario está en un feed y responde a un tweet, funcione. Puedes ejecutar algunas pruebas de integración, funciona, lanzamiento. Luego se implementa una nueva versión. Puedes hacer lo mismo. Puedes probar, lanzar, y así sucesivamente. En este momento, el usuario no respondió, por lo que no ejecutó esa acción. En algún momento posterior, el usuario quiere responder a algún tweet, y luego obtiene la versión tres de este microfrontend. Entonces, la pregunta es, ¿funcionará? Nunca lo probamos, ¿verdad? Podrías probarlo, pero imagina que crece exponencialmente. Cuantas más versiones haya y más micro frontends haya, será un trabajo enorme, por lo que probablemente no lo pruebes. ¿Funcionará? Bueno, la respuesta es que si son completamente independientes, deberían funcionar. ¿Verdad? Así que está bien.

Simplemente los hacemos completamente independientes. Si piensas que esto es como un caso extraño, que no sucedería que despliegues, navegues a una página y luego haya muchas versiones desplegadas hasta que ejecutes una acción. No sé tú, pero todos estos servicios, abro una pestaña y las mantengo durante mucho tiempo. ¿Verdad? Así que Spotify, Mirror también. Es un caso común en muchas aplicaciones.

Así que hay una tensión entre estas dos cosas. Tienes tus micro frontends. Quieres hacerlos súper independientes para ser altamente escalables, pero luego vas a afectar el rendimiento y la consistencia de la interfaz de usuario porque entonces necesitarás compartir cosas. Y muchas veces veo que nos enfocamos mucho en los micro frontends como objetivo final. Oh, queremos ser independientes y autónomos. Y así pensamos en esa parte de la definición. Pero creo que deberíamos enfocarnos más en esta parte, ¿verdad?, y pensar en cómo vamos a componer las aplicaciones porque si fallamos en esa parte, entonces todo lo que viene después estará mal.

Pero aquí hay algunos principios que se me ocurrieron cuando intenté construir micro frontends componibles o descomponerlos. Uno es que deben estar débilmente acoplados. Y aquí la idea es que deben tener fronteras sólidas, buenas interfaces, interfaces bien definidas, tus aplicaciones más pequeñas, los micro frontends, no deben tener dependencias y las dependencias deberían ser idealmente en tiempo de compilación. Eso te dará micro frontends débilmente acoplados. También deben ejecutarse de forma independiente. Porque si realmente puedes ejecutar, puedes ejecutar tu micro frontend de forma independiente sin mucha simulación y ceremonia a su alrededor, significa que está débilmente acoplado. De lo contrario, tendrías que hacer mucho trabajo. Luego puedes trabajar de forma autónoma. No necesitas coordinarte con otros equipos. Puedes reducir la carga de la comunidad al ejecutar todo eso. ¿Verdad? Solo ejecutas un pequeño subconjunto de tu aplicación en un contexto más pequeño. Y así, puedes desarrollarlo de forma autónoma. Y luego debe estar enfocado en un dominio empresarial. ¿Verdad? Porque también he visto ejemplos donde las personas despliegan componentes de forma independiente, pero un componente es una construcción del desarrollador. Lo usamos para resolver problemas empresariales. Así que debes pensar en el dominio empresarial. De lo contrario, si tu dominio empresarial es demasiado pequeño, será muy difícil hacerlo débilmente acoplado. Y sufrirás.

El primer paso que podríamos hacer es crear paquetes. Ya sabes, tal vez los despliegues de forma independiente o tengas un monorepo, no importa, tienes un paquete. Es una forma de encapsular el código. Y también puedes construir ese paquete de forma independiente. En lugar de construirlo todo junto con todo el código en tu monolito, podrías tener una compilación para eso. También puedes, si estás construyendo múltiples paquetes, paralelizarlo para obtener un ciclo de retroalimentación más rápido. También puedes ejecutar esos paquetes. Así estás desarrollando de forma autónoma. Y luego el último paso, lo que harías es, OK, voy a desplegar esto en algún lugar y lo voy a componer en algo en tiempo de ejecución.

Entonces lo que propongo es, ¿por qué no nos detenemos ahí? Enfoquémonos en las otras partes, hagamos un buen trabajo en su construcción. Y tal vez no tengas que desplegar de forma independiente, y tal vez si lo haces, entonces en realidad tienes una buena base para hacerlo. Así que lo que propongo es crear una nueva construcción, que es una aplicación componible. Un primitivo, no el componente. No pensarás en un componente cuando estés construyendo estos micro frontends, pero tienes una aplicación componible, ¿verdad? Que funciona con los principios que acabo de describir. Y luego con esta aplicación componible, es como con los componentes, ¿verdad? Solo los colocas en diferentes lugares. Y no importa si quieres hacer composiciones en tiempo de compilación, en tiempo de ejecución, porque esa es una decisión que a veces debemos tomar de antemano. Como, oh, voy a descomponer este monolito. ¿Qué vamos a hacer? ¿Vamos a hacerlo en tiempo de compilación o en tiempo de ejecución y luego nos comprometemos con eso? Con eso hasta el final. Y también puedes decir, bueno, tal vez alguna parte de mi monolito sea en tiempo de compilación. Porque el tiempo de compilación me dará más rendimiento. Puedo hacer más eliminación de código no utilizado, puedo compartir algunos estados, etc. Y esta otra parte será en tiempo de ejecución, ¿verdad? Puedes combinar todo esto. Otra cosa que puedes hacer, que es lo que voy a hacer hoy, es tener tiempo de ejecución en desarrollo. Así que ahora voy a mostrar una demostración de un pequeño monolito.

Lo dividiré en aplicaciones más pequeñas. Y aplicaciones componibles. Y también las ejecutaré en runtime. Ejecutaré la composición en desarrollo. Así que ya puedes experimentar con micro frontends. Y puedes seguir haciendo tu implementación monolítica, lo cual no suena muy atractivo, pero si piensas en que todas tus pruebas de calidad son iguales, toda tu infraestructura es la misma. No tendrás que convencer a nadie en tu empresa para hacer esos cambios. Así que es solo un cambio arquitectónico.

Para la demostración, voy a usar tres paquetes. Si te gusta lo que vas a ver, puedes explorarlo más tarde. Básicamente es una implementación de estas ideas que estoy mencionando de construir aplicaciones componibles. Así que déjame ver si lo estoy ejecutando. De hecho, lo voy a ejecutar de nuevo, solo por si acaso.

Así que para la demostración, pensé en crear una aplicación ficticia, y esta aplicación es una plataforma para desarrolladores creativos. Todos somos creativos, así que puedes unirte a esta plataforma. Y la idea es que, con código, vas a crear arte, ¿verdad? Y soy el único artista en este momento en esta community. Te mostraré mi obra artística. Así que se llama, esto es un planeta. Tiene este rectángulo que se mueve. Puedo interactuar con él y hacerlo más grande y más grande, y más grande y más grande. Y lo llamo Zima Blue. Vale, no necesitas entender mi arte para que yo me sienta un artista. Pero si ves Love, Death, and Robots en Netflix, tal vez, no sé, simplemente me pareció muy divertido. De todos modos, volviendo a la ingeniería.

Permíteme mostrarte lo que tenemos. Así que tenemos este monolito. ¿Es lo suficientemente grande? Sí, lo es. Así que tenemos este monolito. Es un monorepo, un monorepo clásico con paquetes y así sucesivamente.

Lo que quiero mostrarte es que todo se ejecuta en un árbol de componentes, ¿verdad? Porque esta es una aplicación monolítica. Entonces, una cosa que podría hacer es dividirlo en partes más pequeñas, como el chat, por ejemplo. Este chat está en un paquete, así que lo extraje en un paquete. Genial.

Nada me impide leer Redux que es utilizado por otra parte del monolito. Y así puedo usarlo en mi chat. Y ahora, OK, tengo esta dependencia de runtime. Tal vez pueda usar algún estado de Redux. Voy a decir, oh, usaré este valor que otro equipo mantiene. Y luego lo cambian, y luego mi chat deja de funcionar porque lo estaba usando. Entonces, lo que voy a hacer ahora es cambiar eso a no ser un componente, sino un laboratorio componible, ¿verdad? Así que puedo ir y navegar a esta cosa. Así que tengo el chat aquí. El código es el mismo, pero simplemente lo puse en un paquete diferente. Estos laboratorios componibles son solo otro espacio de trabajo, y es un archivo JSON de paquete.

Y lo que hago es, en lugar de exportar mi componente, exporto una aplicación componible. Así que puedo venir aquí y decir, quiero alojar esta aplicación aquí. Así que si ahora ejecuto mi código, tengo esta otra aplicación de chat. Entonces, si intento leer de React, de Redux, el almacenamiento en el contexto, fallará, porque son aplicaciones diferentes. Así que estás creando límites más sólidos aquí. Así que más desacoplado. Puedo hacer lo mismo en este caso. Solo para el ejemplo, estaba usando suspense y fallback es la misma idea. Así que esto es una importación dinámica. También puedo navegar a esta cosa. Lo mismo, tengo mi obra de arte que la mitad de ella la copié de internet.

Veamos. Ahora puedo ver que tengo otra aplicación aquí. Si no me gusta esto, también necesitas tener un plan de contingencia si intentas convencer o hacer cambios en tu arquitectura. ¿Qué pasa si tomas este camino y te das cuenta de que no es un buen enfoque para ti? Podrías venir aquí y decir, voy a exportar a este tipo y luego con la sintaxis adecuada. Es solo un cambio muy fácil. Tienes un componente, estás usando un componente. Obviamente, en tu aplicación, no usarías el host. Solo lo harías como lo hicimos aquí. Podríamos simplemente poner tu componente aquí. Así que es muy fácil cambiar de uno a otro.

La cosa es que esta es una compilación monolítica. Todo está construido en la misma configuración de webpack. Así que si voy al chat y lo rompo, obviamente se rompe, obviamente se rompe porque es la misma compilación. Así que ahora lo que voy a hacer es cambiar a la composición en tiempo de ejecución. Voy a probar esta composición en tiempo de ejecución. Y lo que voy a hacer es en mi webpack tengo este plugin de los paquetes de linjs. Y voy a decir, estos dos van a ser, si no estoy en producción, porque de lo contrario estaríamos haciendo micro frontends en producción. Y la charla de hoy trata sobre que no hacemos micro frontends. Pero aún puedo hacerlo en desarrollo. Quiero experimentar con esta runtime. Tendré que detener y volver a iniciar. ¿Sigue roto esto? No. Así que debería estar funcionando. Así que obtuve el mismo resultado, diferentes árboles de componentes. Pero si recargo, falla. La razón es que ahora son compilaciones independientes. Son aplicaciones independientes. Tenemos que ir y ejecutarlas. Voy a ejecutar a este tipo y a este tipo. Si recargo la página, está funcionando.

Puedo ver las paquetes en la pestaña de Red, y veré que algunos de estos. Ahora también hay más paquetes. No voy a entrar en detalles. Pero hay Module Federation en el fondo haciendo esta cosa.

Tampoco necesitas usar Module Federation. Puedes usar esta arquitectura, y más adelante, es como, oh, Module Federation, ya no queremos usarlo porque queremos usar, no sé, ROLAP o ES build, lo que sea. Y no está implementado allí. De acuerdo, simplemente no hagas composición en tiempo de ejecución. Recurre a la composición en tiempo de compilación. Y tal vez en el futuro haya un complemento en esas herramientas de compilación.

Y en el CAI, cada vez que inicias un micro-frontend, lo registras en un proxy para que yo pueda ver los micro frontends que se están ejecutando aquí. Puedo ejecutarlos de forma independiente. Funcionan. Y si, no sé si es una buena forma de terminar mi demo. Pero si rompo mi aplicación, la volveré a romper. Así que obtienes esta superposición porque la otra compilación está enviando un mensaje a esta aplicación, la shell. Y está diciendo, eh, la otra falló. Pero en realidad, la compilación del monolito no falló. O no el monolito. Llamémoslo la aplicación shell. Puedo cerrar esto y seguir navegando. Sabes, puedo usar el chat. Puedo ir aquí porque la shell en realidad, funciona porque la compilación no falló. Y si quisieras, podrías llegar hasta el final y decir, sabes qué, voy a hacer micro frontends en producción. Pero no vamos a hacer eso hoy. Porque de lo contrario, mi charla no sería mi charla. Así que no estamos haciendo micro frontends. Vamos a implementar micro frontends sin micro frontends en producción. Y finalmente, esa fue mi charla. Muchas gracias.

Espero que hayas disfrutado. Y puedes probar cualquiera de estas herramientas si quieres. Solo para mencionar, esta idea de aplicaciones componibles solo funciona en el lado del cliente. Y estamos experimentando con el lado del servidor. Entonces, la idea sería que dividas tu aplicación en microaplicaciones o aplicaciones componibles. Puedes hacerlo en tiempo de ejecución o en tiempo de compilación, en el servidor o en el cliente. No importa realmente para tu aplicación. Es como una construcción simple.

Muchas gracias. Muchas gracias, Alex. Realmente aprecio la charla. Siéntete libre de ponerte cómodo. Ven a tomar asiento conmigo. Vamos a tener una sesión de preguntas y respuestas en vivo. Así que en caso de que no lo hayas hecho, siéntete libre de unirte a Slido y ve a la URL de seguimiento, y tus preguntas llegarán. Y podré hacer preguntas, así que no te preocupes. Incluso si la pregunta es muy difícil o muy fácil. Y las responderemos.

¿Cómo te sientes, Alex? Me siento bien. Sí, me siento bien. Muy emocionado por ver cuáles son las preguntas. Sí, yo también, yo también, yo también. Tenía una pregunta sobre el enfoque lean cuando mencionaste el acrónimo. Y hablaste de reducirlo a un negocio, a una parte del negocio. Por pura curiosidad, porque a veces se piensa en la aplicación desde una perspectiva empresarial, y luego en términos de cuáles son las partes del negocio que esta aplicación está sirviendo, en comparación con pensar en ella como desarrollador. Y tal vez cuáles son las partes de esta aplicación y la forma en que quieres construirla. ¿Dónde trazas la línea en cuanto a dónde debería estar esa frontera, en términos de reducir cada uno de esos diferentes micro frontends? Esa es una muy buena pregunta. Y en realidad no es fácil implementarlo correctamente a menos que ya tengas una buena organización de tus equipos. No es como si como ingeniero, fueras y dijeras, oh, necesito encontrar cómo dividir esto de la nada. Es como si miraras a tus equipos.

Y probablemente una forma de comenzar es un equipo, una aplicación. O podrías tener un equipo, múltiples aplicaciones. Tener una aplicación, múltiples equipos, como si dividieras alguna parte de tu aplicación en algún dominio, y eso es propiedad de muchos equipos, eso tal vez sea una indicación de que podrías ir más profundo en un subdominio más pequeño.

Ahora, eso tiene sentido. Me encanta el enfoque orientado a las personas también.

Tenemos algunas preguntas que llegan en Slido. Una de las primeras fue, ¿puedes explicar más detalladamente qué hace realmente una aplicación componible? Así que en el fondo, la idea es que cuando compones cosas, tienes una entrada y una salida, ¿verdad? Entonces es alguna aplicación que puedes incrustar en cualquier lugar de tu aplicación. Puedes tener una aplicación componible alojada por otra aplicación componible. Así que puedes cambiarlas. Básicamente son aplicaciones que puedes agregar a tu aplicación, una dentro de la otra. Y puedes moverlas en tu aplicación. Y simplemente funcionan. No les importa dónde se muestren o alojen realmente. Estoy realmente emocionado, especialmente cuando entras en las DevTools y ves las múltiples rutas. Así que definitivamente quiero ir a verificar eso y probarlo.

Y otra persona ha hecho una pregunta. ¿Qué pasa con la gestión del estado en Microfrontends? Creo que eso es parte de lo que trata tu charla, saber cuándo y cuándo las cosas deben compartir estado, tal vez cuándo no deberían. Pero, ¿qué pasa con la gestión del estado? ¿Tienes algo de lo que puedas hablar al respecto?

Entonces, sí, quiero decir, si quieres tener Microfrontends completamente independientes y muy confiables para que no fallen, probablemente no compartas ninguna gestión del estado. No uses ninguna gestión del estado porque no vas a compartir ningún estado. La realidad es que probablemente tendrás que compartir cierto estado. Por ejemplo, siempre menciono el caso del idioma, si tienes diferentes idiomas. Entonces, lo que recomiendo es que cuando compartas un estado, no compartas la lógica que manipula ese estado. Por ejemplo, Redux podría no ser una buena opción en este paradigma porque Redux también tiene la lógica, el comportamiento que manipula el estado. Como, obtener los datos, inicializar los datos. Y quieres que el comportamiento esté dentro de los límites de esos dominios empresariales. Entonces, sí, tal vez compartas cierto estado. Pero no compartas la lógica que cambia el estado. Creo que la respuesta clásica es, depende, ¿verdad? Y siento que esa es la respuesta.

Y esto se relaciona con el siguiente tema, que trata sobre la compartición de datos entre aplicaciones y lo importante que es. También se habló sobre el acoplamiento accidental. Ya lo mencionamos en la charla anterior. Me gusta mucho la 'L' en Lean, que representa el acoplamiento flexible. Entonces, ¿hay algún consejo, y esto se basa en lo mismo, sobre cómo compartir esa información para evitar acoplarse demasiado?

Sí, en la biblioteca, como también se mencionó en las preguntas que se hicieron antes, tus aplicaciones componibles como una construcción. Sabe muy poco del exterior, tal vez solo el enrutamiento. Así que puedes cambiar cosas. Puedes colocar tu aplicación en cualquier lugar. Y no necesitas recargar la página. Hay ciertas cosas que tu aplicación componible conoce del exterior. Y no puedes cambiarlas. No puedes agregar más props y cosas así. Por lo tanto, debes mantener las dependencias que ingresan muy, muy mínimas. ¿De acuerdo? Pero puedes tener algunas. Por ejemplo, quieres saber cuál es el estado que tal vez estemos compartiendo. Debes intentar mantenerlo muy bajo. Y lo que también debes hacer es no tener dependencias. Ningún código debe depender de tu aplicación. Eso es algo más fácil de hacer que no tener dependencia. Por lo tanto, algunas dependencias como el estado, muy pocas dependencias, y así podrás tener un acoplamiento flexible. Como dije en la charla, si puedes ejecutar tu microaplicación, aplicación componible de forma independiente sin tener que agregar muchas cosas, entonces está bastante acoplada de forma flexible. Si no puedes, entonces revisa el código.

Ahora eso tiene mucho sentido. Ha llegado otra pregunta. ¿Cómo puedes compartir cosas como la configuración regional o una caché de GraphQL entre aplicaciones en tiempo de ejecución independientes? Básicamente, haces un compromiso en esa cosa que estás compartiendo. Entonces las estás haciendo menos independientes. Lo que normalmente hago, en realidad, en ling.js, las bibliotecas, tenemos en el núcleo una función llamada crear un runtime. Básicamente, creas un runtime que compartes en tiempo de ejecución. Ahora, eso no es algo bueno, porque estás haciendo que tus aplicaciones dependan más y podrían fallar. Pero al menos lo haces de manera controlada.

Y tienes acceso restringido a quién puede realmente agregar cosas a ese estado compartido. No estado compartido, tiempo de ejecución compartido. Y también puedes usar TypeScript para hacer validaciones durante el desarrollo para asegurarte de que las personas entiendan qué se comparte y qué no. Y también puedes tener validación en tiempo de ejecución. Entonces, las personas que usan ts-ignore, tampoco pueden usar cosas en el tiempo de ejecución compartido. ts-ignore. Me encanta eso. Me encanta eso.

Amigos, muchas gracias por sus preguntas. Ahora, sé que hay algunas otras preguntas a las que no pude responder. Pero pueden hablar con Alex. Alex se dirige a la sala de oradores. Si se están uniendo de forma virtual, pueden ir a Discord. Y Alex también responderá sus preguntas en la sala de oradores. Y no duden en hablar con él. Pero continuaremos. Demos otro gran aplauso a Alex.