Adoptando Micro-Frontends Sin Micro-Frontends

Rate this content
Bookmark

Los micro-frontends ayudan a descomponer aplicaciones front-end monolíticas en aplicaciones independientes y desacopladas que se pueden implementar de forma independiente. Esta arquitectura nos ayuda a escalar proyectos a medida que la organización crece, sin embargo, también aumenta la complejidad. ¿Cómo podemos aprovechar esta arquitectura sin tener que enfrentar su costo inicial? En esta charla, mostraré algunos de los riesgos asociados con los micro-frontends y qué patrones y bibliotecas podemos utilizar para beneficiarnos de este estilo arquitectónico sin tener que adoptar completamente los micro-frontends.

30 min
21 Oct, 2022

Video Summary and Transcription

La charla de hoy explora la adopción de micro frontends sin implementarlos realmente. Los principales beneficios de los micro frontends son la escalabilidad empresarial y la capacidad de implementar y componer aplicaciones front-end de forma independiente. El proceso de descomponer un monolito en partes más pequeñas se puede realizar utilizando los principios LEAN y aplicaciones componibles. La gestión del estado y el intercambio de datos en los micro frontends son temas complejos que requieren una cuidadosa consideración para evitar el acoplamiento y mantener el desacoplamiento.

Available in English

1. Introducción a los Micro Frontends

Short description:

Hoy voy a hablar de adoptar micro frontends sin micro frontends. ¿Qué es un microfrontend? Es un estilo arquitectónico donde las aplicaciones frontend independientes se componen en un todo mayor. El principal beneficio de los microfrontends es la escalabilidad empresarial. Sin embargo, existen desventajas como problemas de rendimiento y consistencia.

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.

2. Confiabilidad y Micro Frontends

Short description:

Puedes crear un sistema de diseño con diferentes versiones. La confiabilidad es crucial para la ejecución del código. Tomemos como ejemplo Twitter. Dividiéndolo en micro frontends, tenemos un micro frontend para el feed y otro para las respuestas. Se pueden implementar diferentes versiones, pero si son independientes, deberían funcionar.

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.

3. Construyendo Micro Frontends Componibles

Short description:

Necesitamos enfocarnos en componer micro frontends y asegurarnos de que estén débilmente acoplados. Fronteras sólidas, interfaces bien definidas y dependencias mínimas son clave. Ejecutar micro frontends de forma independiente permite la autonomía y reduce la coordinación. Estrechar el enfoque en el dominio empresarial es crucial para un acoplamiento débil y evitar dificultades.

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.

4. Descomponiendo un Monolito con Principios LEAN

Short description:

Los principios LEAN se pueden aplicar para descomponer un monolito en partes pequeñas. El primer paso es crear paquetes, encapsular el código y construirlos de forma independiente. Paralelizar la construcción de múltiples paquetes permite un ciclo de retroalimentación más rápido. Ejecutar estos paquetes permite un desarrollo autónomo. El último paso es desplegar y componerlos en tiempo de ejecución. Para mejorar aún más el proceso, se puede utilizar una nueva construcción llamada una aplicación componible, que permite composiciones en tiempo de compilación y tiempo de ejecución. Este enfoque proporciona flexibilidad y optimización de rendimiento.

Los otros principios sufrirán si tienes cosas muy, muy pequeñas. Así que convertí esto en un acrónimo que llamo LEAN. Así que apliquemos estos principios LEAN para descomponer un monolito. Y aquí hay un ejemplo. Tenemos este monolito y queremos descomponerlo en partes pequeñas.

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.

5. Descomponiendo la Implementación Monolítica

Short description:

Lo dividiré en aplicaciones más pequeñas y aplicaciones componibles. 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.

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.

6. Introducción a la Demo

Short description:

Voy a crear una aplicación ficticia, una plataforma para desarrolladores creativos. Con código, crearás arte. Te mostraré mi obra artística llamada Zima Blue. Es un planeta con un rectángulo en movimiento con el que se puede interactuar y hacerlo más grande. Volviendo a la ingeniería.

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.

7. Explorando la Descomposición del Monolito

Short description:

Permíteme mostrarte lo que tenemos. Tenemos un monolito, un monorepo clásico. Lo dividí en partes más pequeñas, como el chat. Extraje el chat en un paquete. Lo convertí en una aplicación componible, creando límites más sólidos y un mayor desacoplamiento. La misma idea se aplica a las importaciones dinámicas. Tengo una obra de arte.

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.

8. Cambiar a Composición en Tiempo de Ejecución

Short description:

Ahora puedo ver otra aplicación aquí. Si te das cuenta de que este enfoque no funciona para ti, es fácil hacer cambios. Solo exporta y usa el componente. Sin embargo, en una compilación monolítica, romper una parte afecta a las demás. Cambiar a la composición en tiempo de ejecución permite compilaciones independientes. Ejecutar las aplicaciones por separado garantiza que funcionen correctamente.

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.

9. Module Federation and CAI

Short description:

Puedo ver las paquetes en la pestaña de Red. Module Federation está en el fondo, pero no es necesario. Si no quieres usarlo, puedes recurrir a la composición en tiempo de compilación. En el CAI, los micro frontends se registran en un proxy y pueden ejecutarse de forma independiente. Romper la aplicación no afecta a la shell. Puedes seguir navegando. No estamos haciendo micro frontends en producción, pero los implementamos sin micro frontends. Gracias.

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.

QnA

Conclusion and Q&A

Short description:

Esta idea de aplicaciones componibles solo funciona en el lado del cliente. Puedes dividir tu aplicación en microaplicaciones o aplicaciones componibles, independientemente de si es en tiempo de ejecución o en tiempo de compilación, en el servidor o en el cliente. Muchas gracias. Vamos a tener una sesión de preguntas y respuestas en vivo. Me siento bien y emocionado por ver las preguntas. Cuando se trata de reducir los micro frontends a un negocio, es importante tener una estructura de equipo bien organizada.

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.

Estructura del Equipo y Aplicaciones Componibles

Short description:

Una forma de comenzar es un equipo, una aplicación. Otra opción es un equipo, múltiples aplicaciones. Las aplicaciones componibles te permiten incrustar componentes en cualquier lugar de tu aplicación. Pueden ser alojados por otras aplicaciones componibles y pueden moverse libremente. Este enfoque proporciona flexibilidad y emocionantes posibilidades, especialmente al explorar múltiples rutas en las herramientas de desarrollo.

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.

Gestión del Estado en Microfrontends

Short description:

La gestión del estado en Microfrontends es un tema complejo. Si bien los Microfrontends completamente independientes pueden no compartir ninguna gestión del estado, en realidad puede ser necesario compartir cierto estado. Sin embargo, es importante evitar compartir la lógica que manipula el estado. Por ejemplo, Redux puede no ser adecuado en este paradigma, ya que incluye la lógica para la manipulación del estado. La clave está en mantener el comportamiento dentro de los límites de los dominios empresariales.

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.

Compartir Datos y Evitar el Acoplamiento

Short description:

Compartir datos entre aplicaciones es crucial y es importante evitar el acoplamiento accidental. El concepto de acoplamiento flexible es esencial. Para compartir información sin acoplarse demasiado, mantén las dependencias mínimas y evita la dependencia del código en tu aplicación. Enfócate en mantener un nivel bajo de estado compartido y revisa el código si es necesario. Cuando compartas cosas como la configuración regional o una caché de GraphQL entre aplicaciones en tiempo de ejecución independientes, hay un compromiso en hacerlas menos independientes. Un enfoque es crear un tiempo de ejecución que se comparta en tiempo de ejecución, aunque esto aumenta la dependencia y lleva el riesgo de fallos.

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.

Shared Runtime and Q&A

Short description:

Tienes acceso restringido al tiempo de ejecución compartido. TypeScript se puede utilizar para validaciones durante el desarrollo para garantizar la comprensión de los componentes compartidos. La validación en tiempo de ejecución evita que aquellos que ignoran las advertencias de TypeScript utilicen el tiempo de ejecución compartido. Gracias por sus preguntas. No dudes en contactar a Alex para consultas adicionales.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
20 min
Micro-Frontends With React & Vite Module Federation
From my experience one of the hardest things is to share information between microfrontends, so in this talk I would like to explain various ways on how to share a design system to ensure uniformity to the application. Another difficult thing is sharing dependencies, fortunately with module federation it can be done, but how can I use different versions of the same library and how does it work behind the scenes?
I'm the creator of module-federation/vite library, with React and this library, I'd like to show you how you can achieve these results by configuring everything correctly.
React Summit 2022React Summit 2022
23 min
Sharing is Caring: (How) Should Micro Frontends Share State?
Micro frontends architecture is extremely powerful when it comes to splitting large frontend monoliths into smaller, individually deployable blocks, each is owned by an autonomous team and is focused on a business domain. But what about State? We are often told that micro frontends shouldn't share state, as this would make them coupled to each other. However, when it comes to complex UIs, it is not rare to encounter scenarios where state management between micro frontends is necessary. This talk is about finding the sweet spot — In which scenarios it is reasonable for micro frontends to share State? and how should micro frontends share State while remaining decoupled of each other? We discuss & compare different solutions in React.
React Advanced Conference 2021React Advanced Conference 2021
27 min
Micro-Frontends Performance and Centralised Data Caching
Common myths about Micro-Frontends hold that they are bad for performance or that developers implementing this architectural style don’t care about the performance implications because they are focusing on fixing the developer experience and organizational issues rather than focusing on the user experience, however, the reality is altogether different. Micro-Frontends are not inheritably bad for performance and, as is often the case in software development, making best use of the technology depends on correct implementation. This talk will demonstrate how Micro-Frontends can make your applications faster and more resilient while keeping the benefits of independent deployments.

Workshops on related topic

JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Workshop
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
JSNation Live 2021JSNation Live 2021
113 min
Micro-Frontends with Module Federation and Angular
Workshop
Ever more companies are choosing Micro-Frontends. However, they are anything but easy to implement. Fortunately, Module Federation introduced with webpack 5 has initiated a crucial change of direction.
In this interactive workshop, you will learn from Manfred Steyer -- Angular GDE and Trusted Collaborator in the Angular team -- how to plan and implement Micro-Frontend architectures with Angular and the brand new webpack Module Federation. We talk about sharing libraries and advanced concepts like dealing with version mismatches, dynamic Module Federation, and integration into monorepos.
After the individual exercises, you will have a case study you can use as a template for your projects. This workshop helps you evaluate the individual options for your projects.
Prerequisites:You should have some experience with Angular.