Desafíos de Descomponer un Front-End Masivo Usando Micro-Frontends

Rate this content
Bookmark
Slides

Nuestra aplicación de interfaz de usuario web es bastante grande: cientos de personas la han estado construyendo activamente durante los últimos ocho años. Comenzamos a enfrentar problemas de escalabilidad y limitaciones tecnológicas. Evaluamos muchas opciones y nos decidimos por los micro-frontends. Esta noche discutiremos:

- Diferencias entre varias arquitecturas de micro-frontends

- Por qué tomamos esta decisión y si es útil para ti

- Lo que ganamos

- Lo que sacrificamos (sí, hay desventajas)

- Qué desafíos aún tenemos por delante

28 min
08 Dec, 2023

AI Generated Video Summary

Los microfrontends ofrecen una solución potencial a los problemas de ingeniería de frontend, mejorando la eficiencia de las pruebas y permitiendo un desarrollo más rápido. Hay conceptos erróneos sobre los microfrontends, con diferentes enfoques como las divisiones horizontales y verticales. Se recomiendan los monorepos para gestionar los microfrontends. La gestión de datos y los efectos secundarios se pueden manejar a través de varios enfoques. Construir microfrontends sin un monorepo puede ser un desafío, pero depende de la escala de la aplicación. La confianza en las personas y la implementación de un registro de componentes ayudan a evitar la duplicación. Herramientas como Module Federation y NX son útiles para gestionar microfrontends.

1. Un Sueño, Deber de Paginación, y Microfrontends

Short description:

Es un día agradable y soleado. Estás deslizándote por los fiordos. El agua te consume. Miras tu teléfono y ves una notificación de deber de paginación. Entiendes el problema, pero es causado por alguien que ni siquiera es un ingeniero de frontend. Lo arreglas, pero te encuentras con problemas. Finalmente, fusionas tus solicitudes de extracción. Microfrontends es una posible solución a este problema.

Es un día agradable y soleado. Te deslizas por los fiordos. Los agradables rayos del sol caen sobre los frondosos bosques y esos fiordos. Has soñado con tener estas vacaciones durante mucho tiempo. Estás verdaderamente feliz hasta que algo sale mal.

El agua te consume. Pierdes el control. No entiendes lo que está pasando hasta que te despiertas. Ha sido un sueño. Ha sido un mal sueño y algo te ha despertado claramente. Miras tu teléfono y ves que es una notificación de deber de paginación. Tienes un deber que hacer.

Molesto, te despiertas. Te levantas y vas perezosamente a tu ordenador para ver qué ha pasado. Después de algunos minutos de mirar el problema, entiendes cuál es. Sin embargo, estás extremadamente molesto porque no es causado por tu equipo, sino por alguien que ni siquiera es un ingeniero de frontend.

Golpeas la mesa porque estás enfadado. Olvidas que tienes un hijo que se despierta por tu enfado y ahora tienes que explicar a tu hijo por qué tu padre, el padre de Keith, tiene que arreglar una biblioteca de validation de teléfonos móviles por la noche. Haces la corrección. Abres la solicitud de extracción, que tarda 40 minutos en construirse. Te haces un café mientras esperas, y al final en lugar de una feliz marca de verificación verde, obtienes una cruz roja.

Prueba de despertar de nuevo. Haces clic en el botón de reinicio. Terminas tu té frío para ver tu marca de verificación verde. Fusionas tus solicitudes de extracción. Puedes dormir un par de horas hasta que te despiertes y hagas más trabajo.

Es un ejemplo de una combinación de un problema tecnológico y un desafío organizativo. No debería haber ocurrido. Sin embargo, está ahí. Microfrontends es una de las posibles soluciones para abordar este problema.

2. Microfrontends y Comunicación

Short description:

Hoy vamos a hablar sobre microfrontends. Compartiremos experiencias de diferentes empresas y disiparemos estereotipos en torno a este tema. Al discutir ideas en grupo, la conversación a menudo se expande y se desvía del plan original. Muchas personas pueden relacionarse con esto, ya que puede ser desafiante comunicarse de manera efectiva y tomar decisiones en grupos más grandes. Este concepto se aplica no solo al desarrollo de software, sino también a otras áreas, como la política.

Gracias a todos por venir aquí. Mi nombre es Alex, y hoy vamos a hablar sobre microfrontends. Tuve la suerte o la fortuna de trabajar en tres empresas que hicieron microfrontends. Eran empresas bastante diferentes, y querían compartir su experiencia. ¿Cómo lo hicieron? También, disipar algunos estereotipos que rodean el tema de los microfrontends en general.

Hablemos de tu empresa. Estás trabajando y tienes una idea. Quieres hacer algo muy sencillo, muy simple, muy tangible, y va a tener un resultado muy predecible y claro. Parece fácil, ¿verdad? Hagamos X y vamos a obtener Y. Muy sencillo. Pero no, hay un tipo con opiniones, y ahora tienes que convencerlo de cómo vas a hacer esto. Y al menos su punto tiene sentido, como, entiendo, está bien, veo de dónde vienes. Tengamos una charla. A menos que la discusión se expanda. Se expande en dimensiones que no imaginaste al principio. Y cuanto más avanza, más se desvía del lugar donde comenzó hasta que finalmente se va.

Por favor, levanten la mano quienes puedan relacionarse con la historia. Muchas personas. Y las personas que están sentadas a tu alrededor, las personas que forman parte de esas llamadas, realmente no quieren estar allí. También tienen una vida que vivir y tienen hijos que no quieren saber acerca de las bibliotecas de teléfonos. Hay mucha investigación sobre esto. No es un tema de vanguardia. Estaba Fred Brooks. Era un ingeniero y gerente de ingeniería, hace muchos años, antes de que muchos de nosotros naciéramos. Y escribió un libro. El libro se llama el Mythical Man Mouth, donde describe el concepto de las personas interactuando a escala. Y cuanto más grande es el grupo, más difícil es para las personas comunicarse de manera efectiva y tomar decisiones. Hay conceptos similares y diría que es lo suficientemente creíble como para hacer nuestras suposiciones sobre esto. Y también se aplica a diferentes esferas de nuestra vida. Si observas la política, por ejemplo, los países que están profundamente descentralizados, tienden a ser más efectivos en su autoadministración.

3. Desafíos con Autonomía y Límites

Short description:

Podrías preguntarme, está bien, tuvimos discusiones de cinco minutos. Nos convenciste de que deberíamos dividirlo. ¿Por qué seguimos aquí? Dividimos los equipos y les dimos plena autonomía. Así que tenemos diferentes características y han sido trabajadas por personas en esas características.

Podrías preguntarme, está bien, tuvimos discusiones de cinco minutos. Nos convenciste de que deberíamos dividirlo. ¿Por qué seguimos aquí? Dividimos los equipos y les dimos plena autonomía. Así que tenemos diferentes características y han sido trabajadas por personas en esas características. Y tienes un pequeño equipo con dos personas cuando alguien quiere usar algo y el otra persona es como, sí, vamos, solo vivimos una vez. ¿Por qué no deberíamos hacer esto? Es divertido. Va a ser genial ponerlo en nuestro CV. Hagámoslo. Así que estás feliz y estás teniendo un día libre en tu vida. Hasta que no. Hasta que entiendes que probablemente cruzaste algún límite, que no deberías haber cruzado y causaste algunos problemas que aún no entiendes completamente.

4. Eficiencia de las Pruebas y Microfrontends

Short description:

Las empresas necesitan confiar en pruebas automáticas para desplegar su software con frecuencia. Sin embargo, ejecutar estas pruebas puede ser un proceso lento e inestable, causando frustración para los ingenieros. Cambiar a microfrontends puede mejorar significativamente la eficiencia de las pruebas, reduciendo el tiempo de 45 minutos a 5 minutos. Esta mejora permite a los desarrolladores construir más rápido y evitar fallos globales. Además, los microfrontends permiten a las empresas utilizar nuevas tecnologías y mejorar sus pipelines, reduciendo costos y fallos de un solo punto.

Las empresas y preguntas de las que vamos a hablar son una escala local de los Países Bajos y aún muy grandes, quiero decir, no muy grandes, pero algo grandes empresas de software como servicio. Puedes hacerte una idea aproximada del tamaño de estas empresas y las empresas más grandes tienen un verdadero CICD y despliegan mucho.

Y si quieres desplegar como 15 o, por ejemplo, 77 veces al día, no puedes probar tus cosas manualmente. Tienes que confiar en pruebas automáticas, testing por ti. Y las pruebas toman tiempo y cuanto más grande es tu aplicación y más compleja es la lógica de negocio de tu aplicación, más tiempo lleva ejecutar tus pruebas. Y este no es un ejemplo ficticio de lo que puede ser. Y ese no es el peor ejemplo. Y ese es el resultado de esfuerzos continuos de varios años para reducir este número. Así que es como muchas máquinas potentes gastando mucha electricidad en algún lugar de América ejecutando tus pruebas en el pipeline solo para fallar. Así que otro problema de las pruebas de extremo a extremo es que es muy difícil hacerlas estables, especialmente si ejecutas muchas de ellas en paralelo, en realidad también creas algún tipo de concurrencia y lo que uses como backend para tu prueba de extremo a extremo también necesita ser fiable. Así que sí, imagina que tienes que rehacer esta operación a menudo y a menudo, una y otra vez, y eso hace que tus ingenieros estén algo infelices.

Este es un ejemplo de cuán masiva puede ser la mejora al cambiar a microfrontends. Dado que cada microfrontend puede tener una prueba que está dedicada a este microfrontend específico, puedes tener una buena idea de lo que se necesita para probar el microfrontend específico. Estos son los números reales para nosotros. Pasamos de 45 minutos en promedio a 5 minutos en promedio, lo cual fue una mejora realmente agradable de vida. Por lo general, se estaba construyendo más rápido de lo que el desarrollador estaba escribiendo en la descripción de los tickets, así que estábamos increíblemente felices. Eventualmente, tuvimos que extender esos con un par de pruebas de extremo a extremo en toda la plataforma solo para asegurarnos de que no arruinamos globalmente. Pero aparte de eso, no se hicieron cambios masivos. Si no está claro qué es.

Además de eso, podemos ver que hubo mejoras adicionales. En el caso de FreshBooks y 3Way 42, nos permitió utilizar nueva tecnología. 3Way estaba atascado con la primera versión de Angular. FreshBooks estaba usando Ember. Y no estoy seguro si alguien todavía usa Ember aquí. Es en realidad un marco funcional que se está manteniendo. Así que no está exactamente obsoleto. Sin embargo, es difícil encontrar personas que quieran hacer Ember. Es difícil encontrar tecnologías modernas que soporten Ember y demás. Y en el caso de FreshBooks y Personio, nos permitió mejorar nuestros pipelines, ejecutar más rápido, reducir el costo de los pipelines porque los ejecutamos más rápido, y también reducir la cantidad de fallos de un solo punto para que la gente se despierte menos. Y por supuesto, la autonomía de las personas.

5. Conceptos Erróneos y Enfoques de División

Short description:

Existen conceptos erróneos sobre los micro-frontends, particularmente con respecto al enfoque de división horizontal donde se utilizan múltiples marcos de trabajo de front-end en la misma página. Otro enfoque es la división vertical, donde se muestra un micro-frontend a la vez, dividido por dominio.

Puedes tomar decisiones y estar algo contento con ellas, hasta cierto punto. Hay un par de conceptos erróneos cuando se trata de micro-frontends. A menudo, la gente piensa en esta imagen de la solicitud de imágenes de Google para micro-frontends donde tienes un tractor y múltiples micro-frontends en la misma página. No puedo recordar cuántas veces me han enviado esta imagen. Y así tienes como un menú en Angular, algo más en React, y el resto de la página en Vue.js. Lo que ves allí se llama división horizontal. Es el enfoque cuando tienes múltiples frameworks de front-end en la misma página. Pero también, hay otro enfoque que se llama división vertical, donde tienes un micro-frontend en la pantalla a la vez donde divides tus aplicaciones por dominio.

6. Desafíos con la Arquitectura de División

Short description:

La división horizontal es funcional y útil, pero no es adecuada para las empresas que construyen microfrontends en la interfaz de usuario. FreshBooks y Persona utilizan la arquitectura de microfrontend de división vertical. Los desafíos incluyen definir la estrategia de migración, dividir los dominios y gestionar las dependencias y los pipelines.

Aunque la división horizontal es funcional y útil, no trabajé en las empresas que podrían beneficiarse de ella en su totalidad. Y normalmente, son las empresas de e-commerce porque pueden renderizar sus micro-fuentes en los back-ends. Pueden enviar el paquete resultante como HTML. Como estamos construyendo nuestros micro-frontends en la interfaz de usuario, no podemos permitirnos tener un tamaño de paquete de 30 megabytes. Era importante para nosotros ser más razonables al respecto.

Tanto en FreshBooks como en Persona, optamos por utilizar la arquitectura de microfrontend de división vertical. Ahora, hablemos de los desafíos. El primer desafío es definir la estrategia de migración. Si tienes un producto grande, no puedes decidir de repente que tienes algo nuevo. Tienes que reiniciar lo anterior y obtener tres años de esfuerzos de desarrollo de algún lugar y construir la cosa. Si eres razonable al respecto, existe un patrón que se llama Patrón más Fuerte, que básicamente te sugiere envolver la cosa vieja en un marco de Fachada y empezar a crecer la cosa nueva al lado de ella hasta que finalmente elimines la cosa vieja. Sé realista, invierte en tooling porque lo más probable es que te quedes atascado en el paso 2 para siempre, así que necesitas sentirte cómodo en esta situación.

Otro desafío es dividir los dominios. El design orientado al dominio no son temas extremadamente simples. Hay muchos libros al respecto. Es un desafío en los back-ends, también es un desafío en los front-ends, y esos desafíos no necesariamente responden a la misma pregunta. Está bien si tus dominios de front-end van a ser diferentes a tus dominios de back-end. Si optas por la arquitectura de división vertical, vas a tener páginas que tienen múltiples dominios de back-end mostrando data. Sin embargo, quieres mantenerlo como un solo micro-fuente. Así que está bien tener diferencias en los límites del dominio. Los dominios muy pequeños pueden hacer que construyas esos múltiples micro-frontends juntos solo para probarlos, porque una prueba va a pasar por múltiples micro-frontends para comprobar el flujo de negocio, lo cual tampoco es perfecto, y una gran cantidad de dominios pequeños puede llevarte al mismo problema con el que empezamos, con alguien arreglando código que nadie posee exactamente.

El tercer desafío es gestionar las dependencias y los pipelines. Lo odio mucho. Es realmente difícil, y lo hicimos mal, completamente mal. Así que el enfoque intuitivo para construir cosas es como, está bien, tengo un estante para esto, tengo un estante para esto, y vamos a separar las cosas. Paquete npm separado para nuestros componentes, sistema de design, paquete separado para ayudantes, hasta que empiezas a juntarlo y a depurar, y hasta que quieres debug tu componente dentro de la aplicación, y entonces tienes el proceso de, está bien, necesito actualizar el componente. Así que vas al repositorio del componente, construyes, cambias los componentes, construyes los componentes, los despliegas en artifactory o npm, lo que uses. Luego actualizas la versión del paquete en tu aplicación, y luego reinstalas las dependencias, y luego puedes ver cómo funcionó. Y si quieres debug algo de CSS simple, se vuelve bastante doloroso. Afortunadamente, hay soluciones, ninguna de las cuales encontramos lo suficientemente útil para nosotros y conveniente para que las usemos.

7. Monorepos y Sus Beneficios

Short description:

Después de comenzar con repositorios separados, utilizamos npm link y sub-repositorios. Sin embargo, finalmente terminamos con un monorepo en ambas empresas. Los monorepos han demostrado ser muy recomendados, y el libro de Ingeniería de Software de Google respalda esta idea.

Entonces, después de comenzar con repositorios separados, decidimos usar npm link, que no nos gustó. Y comenzamos a usar sub-repositorios, que ya era mejor. Nos ayudó a evitar la versión y asegurarnos de que podemos hacer cambios más grandes, y podemos reducir la frustración en torno a diferentes micrófonos que tienen diferentes versiones del mismo paquete. Y sí, finalmente terminamos con un monorepo en ambas empresas. Ambas empresas tuvieron un camino muy diferente hacia él, pero ahora usamos monorepo en ambas. No puedo recomendarles suficientemente los monorepos, y si están interesados en ellos, hay un buen libro que se llama Ingeniería de Software en Google, y afirman que todo Google incluyendo YouTube y demás, es monorepo.

8. Gestión de Datos y Efectos Secundarios

Short description:

La mejor manera de gestionar los datos es no gestionarlos en absoluto, pero si tienes que gestionarlos, puedes tener diferentes enfoques. Primero, puedes iniciar algunos datos cuando inicializas el marco de trabajo en sí. Si quieres intercambiar datos, especialmente si estás utilizando micro-frontends de división horizontal, entonces puedes usar PubSub. Los efectos secundarios son fáciles de pasar por alto pero son directos. Puedes usar iframe o componentes web para aislar los frontends internos de los frontends externos.

Gestionando data. La mejor manera de gestionar data es no gestionarla en absoluto, pero si tienes que gestionar data, puedes tener diferentes enfoques. Primero, puedes iniciar algunos data cuando inicializas el marco de trabajo en sí. Puedes renderizar tu micrófono con algunos data iniciales. Por ejemplo, puede ser tu token de authentication, pueden ser tus cadenas de traducción, pueden ser las configuraciones de tus objetos, como qué esquema de colores están usando, qué mod. Puedes pasarla una vez cuando instancias la aplicación, y luego no te importa si estos data cambian.

Si quieres intercambiar data, especialmente si estás utilizando micro-frontends de división horizontal, donde tienes múltiples frontends en la misma página y necesitan impactarse entre sí, entonces puedes usar PubSub. Cualquier implementación servirá. Puedes usar incluso RxStreams, lo que prefieras. Solo necesitas algo a lo que suscribirte y escuchar. También puedes poner alguna máquina de estado allí. Puedes envolver Redux en PubSub y publicar cambios en Redux si quieres. Todas esas cosas funcionan. Ve lo que funciona para ti.

Efectos secundarios. Algo que es muy fácil de pasar por alto, pero también muy directo. Tienes tu frontend. Pones otros frontends dentro de él. Hasta que entiendes que los frontends internos pueden filtrar cosas en los frontends externos. Puede ser CSS, puede ser JavaScript. Puedes contaminar y romper fácilmente el frontend externo hasta que encuentres medidas efectivas de cómo puedes aislarlos entre sí. Hay diferentes enfoques. Si eres lo suficientemente mayor, puedes usar iframe. También puedes usar web components, que personalmente recomiendo. Fue muy útil para nosotros. Muy fácil de implementar. Muy fácil de salir de él si no te gusta cómo funciona. Son un par de días de trabajo. Puedes confiar en las personas. O puedes usar CSS esculpido.

QnA

Reflexiones Finales y Preguntas y Respuestas

Short description:

Puedes usar BEM o importaciones CSS, módulos CSS para solucionar problemas de CSS. Sin embargo, no resuelve la fuga de JavaScript. Construye una buena aplicación de ejemplo para fomentar la reutilización del código. Invierte en educación para ahorrar tiempo en la refactorización. Automatiza el código repetitivo para una mejor adopción. Considera comenzar con restricciones para estandarizar el código. Ten cuidado con las dependencias y asegura actualizaciones fáciles. Gracias por asistir.

Puedes usar BEM o importaciones CSS, módulos CSS, lo que puedas hacer para esculpir CSS para solucionar los problemas de CSS. Pero no resuelve la fuga de JavaScript.

Antes de concluir, un par de conclusiones generales. Asegúrate de construir una buena aplicación de ejemplo. Seamos honestos con nosotros mismos. Las personas copian y pegan código si pueden. Y si tienes un buen ejemplo de cómo podría ser un buen micro-frontend. Es mejor si las personas copian y pegan tu buen ejemplo que si copian y pegan algo que no es exactamente bueno.

Invierte en educación. Si pasas una semana enseñando a las personas ahora, ahorrarás muchas semanas, tal vez un mes, en la refactorización de su código más tarde. Automatiza el código repetitivo. Especialmente si no tienes el pleno acuerdo en tu empresa para avanzar con los micro-frontends, podría ser una prueba de concepto. Y dependiendo de cómo otros equipos perciban los micro-frontends que construyes. Si les gusta la experiencia de trabajar con micro-frontends, si el nuevo enfoque es mejor que el antiguo enfoque, podrían tener diferentes opiniones sobre si quieren convencer a su gerente para optar por esto o no. Y si tienes una buena herramienta, un buen código repetitivo, y su experiencia de desarrollador es lo suficientemente buena, tienes mejores probabilidades de que esta idea se mantenga.

Levantar restricciones es fácil, pero hacer nuevas restricciones es difícil. Así que si empiezas en el salvaje oeste cuando todo es posible, tendrás un tiempo mucho más difícil imponiendo restricciones más tarde y estandarizando tu base de código. Así que si puedes permitirte empezar en modos más restringidos, lo pasarás mejor. Pero también quiero reconocer que no siempre es posible. Y por favor, echa un vistazo a tus dependencias. Hay tantos agujeros de conejo en los que saltar. Puedes tener cien aplicaciones React con cien versiones diferentes de React. Si te metes en esta situación, no puedes compartir el paquete React entre esos micro-frontends. Básicamente tendrás cien Reacts cargados para tu sitio web. Asegúrate de que puedes actualizar fácilmente los paquetes. Si hay una vulnerabilidad crítica y tienes versiones obsoletas, diferentes versiones del mismo paquete en diferentes repositorios, va a ser doloroso. Así que es una deuda técnica que debes tener en cuenta y debes asegurarte de que te lo has puesto fácil para mantenerte en el futuro.

En esta nota, quiero decir gracias. Realmente aprecio tu asistencia. Gracias y responderemos con gusto a tus preguntas.

Construyendo Micro-frontends Sin un Mono-repo

Short description:

Primera pregunta: ¿Qué tan viable es este enfoque sin usar un mono-repo? Depende de la escala de tu aplicación. Si es un pequeño sitio web de la comunidad local, puedes tener tantos repositorios como quieras. Sin embargo, Persona enfrentó desafíos con la capacidad de descubrimiento y la profundidad técnica al usar un enfoque de multi-repo. Tener un repositorio con múltiples micro-frontends mejora la capacidad de descubrimiento y facilita la revisión de PRs. Para pequeñas aplicaciones greenfield, los micro-frontends pueden no ser necesarios si la complejidad supera los beneficios.

En primer lugar, qué historia tan profunda para comenzar. Me estaba estresando y me desperté. Fue una pesadilla. Estaba algo aliviado. Entraremos directamente en materia. Tenemos unos siete minutos para responder algunas preguntas. Solo un recordatorio, hay una sección de preguntas y respuestas para el ponente cerca de la entrada o para aquellos que están de forma remota en la línea de tiempo. Las que no lleguemos a responder, si aún quieres hacerlas, hazlo después de esto.

Bien, genial. La primera pregunta es ¿cómo crees que este enfoque es viable sin usar un mono-repo? Absolutamente. ¿Cuáles serían las implicaciones de no usar un mono-repo? Sé que dijiste que son muy agradables. Son agradables para trabajar. En mi trabajo diario, trabajo con un mono-repo. ¿Cuánto más difícil es sin él? Realmente depende de cuán grande sea el potencial de escala que tienes en tu aplicación porque algunas aplicaciones nunca están destinadas a escalar. Si estás construyendo el sitio web para tu community local, nunca va a tener millones de clientes y nunca va a ser grande. En este caso, puedes tener tantos repositorios como quieras. Por otro lado, Persona comenzó como un multi-repo y finalmente encontró que tenemos un problema de no saber cuántos micro-frontends exactamente tenemos. Que necesitamos poner esfuerzos continuos solo en descubrir los micro-frontends que se están construyendo. La profundidad técnica se volvió más difícil porque necesitas actualizar algo que es desconocido. No puedes actualizar algo que no sabes que existe. Y eso lo hace bastante complicado en general. Definitivamente es posible. Definitivamente puedes vivir con eso. El último punto es la capacidad de descubrimiento. Si quieres que la gente eche un vistazo a tus PRs, es mucho más difícil conseguir ojos en 100 repositorios que en un repositorio con 100 micro-frontends.

Creo que hay bastantes preguntas aquí que se derivan de esto, y en realidad es sobre ¿cómo trabaja y se comunica un equipo mientras construye micro-frontends? Creo que hay unas cuantas. Podemos llegar a otras similares en un momento. Esta pregunta recibió un montón de votos positivos, pulgares arriba, más unos. ¿En qué momento la complejidad supera los beneficios de los micro-frontends? Si tienes una pequeña aplicación greenfield nueva, diría que no necesitas micro-frontends. Diría que no es el punto cuando empieza a superar.

Beneficios y Evitando la Duplicación

Short description:

Los micro-frontends se vuelven útiles para las grandes aplicaciones cuando se siente el dolor de no tenerlos. Evitar la duplicación a través de los micro-frontends puede ser un desafío, pero la confianza en las personas es clave. Implementar un registro de componentes construidos externamente ayuda a manejar la duplicación. Se recomienda comenzar con una biblioteca de componentes abstractos, como demostró FreshBooks.

Creo que los micro-frontends superan los beneficios cuando comienzas. Y eventualmente, comienzan a tener más sentido a medida que avanzas. Así que diría que para las grandes aplicaciones, tiene sentido. No realmente para las pequeñas. Sí.

Creo que en mi mente, es casi la pregunta inversa. ¿En qué momento los micro-frontends se convierten en algo beneficioso para tu proyecto? Exactamente. Esa es la pregunta. ¿En qué momento crees que se vuelven útiles? En el momento en que sientes el dolor de no tenerlos. Quiero decir, sí. Sí. Vale.

¿Sabes qué? Sí. Tenemos tantas preguntas. Dios mío. Están llegando tan rápido. No he tenido ninguna masterclass con tantas preguntas entrando. Esto es maravilloso. ¿Cómo evitas la duplicación a través de los micro-frontends? Recuerda que dije confía en las personas. Hasta cierto punto, es esto. Claramente no es perfecto, y puede ser mejor. Estamos buscando diferentes medios para encontrar código duplicado, pero no es muy sencillo porque puedes implementar la misma cosa de manera diferente. Actualmente, tenemos un registro de componentes construidos externamente, y estamos trabajando en socializar a través de la organización. Así que si construyes algún componente muy específico del dominio, que no pertenece al design system, al menos hay un lugar centralizado donde puedes ir y ver que este componente existe. Pero sí, el verdadero problema, tenemos ayudantes que se duplican en varios micro-frontends, y eso es solo el precio que pagas, diría yo.

Esta fue una de las preguntas que llegó en realidad mientras estabas respondiendo a esta pregunta, pero solo para ser explícito, ¿se recomienda por lo tanto comenzar con este tipo de biblioteca de componentes abstractos que luego puede ser utilizada por todos los micro-frontends? ¿Es un enfoque común? Es un enfoque que hemos elegido en FreshBooks porque teníamos una ventaja inicial. Así que básicamente construimos un ejemplo de cómo iba a funcionar. No diría prueba de concepto, diría MVP completo. Tuvimos un par de equipos que adoptaron el enfoque más tarde, y fue bastante bueno. Pero en Prestonio, por ejemplo, tuvimos diferentes circunstancias.

Demandas, Herramientas y Gestión de Estado Compartido

Short description:

Tuvimos demandas para el nuevo sistema de diseño y tuvimos que movernos en paralelo con otros equipos. Las herramientas y configuraciones de micro-frontends que funcionaron para nosotros incluyen Module Federation y NX para la gestión de monorepos. En FreshBooks, utilizamos VIT para construir micro-frontends. La gestión del estado compartido se manejó fácilmente con un objeto global, sin mucho sobrecargo. El problema de no poder compartir el estado es más exagerado de lo que realmente es.

Teníamos demandas para el nuevo sistema de design, y teníamos que movernos en paralelo con otros equipos que iban a consumir eso. Realmente depende del estado en el que se encuentre tu organización, y si puedes permitirte gastar dos, tres, cuatro meses de ventaja solo preparándote para... Sí, es una de esas cosas de ir despacio para ir rápido, y sin embargo, no todos los equipos tienen el lujo o el privilegio de poder asumir ese golpe inicial.

Esta siguiente pregunta interesó a muchas personas. Entonces, ¿qué herramientas o configuraciones de micro-frontend han funcionado para ti? Y supongo, ¿cuáles no? Vale la pena hablar de eso también. Sí, diría que prácticamente todo lo que consideramos funcionó lo suficientemente bien. Puedo decir con qué nos quedamos. Usamos Module Federation, y es bastante bueno. Usamos NX para la gestión de monorepos, que también fue bueno. En FreshBooks, hemos probado Module Federation. No justificó las desventajas, que teníamos en el momento. Así que simplemente estábamos construyendo micro-frontends con VIT. Estábamos dividiendo el paquete, como, tamaño de paquete compartido de archivos por separado, como React y otros grandes bloques, que usamos en micro-frontends para que pueda ser compartido. Y teníamos un script bash de 500 líneas, que estaba haciendo lo que se supone que debe hacer Module Federation. Solo fui a la sala y dije, vaya, eso fue un gran script bash.

Creo que tenemos tiempo realmente rápido para esta, que me intrigó en tu charla también, porque mencionaste el uso de PubSub u otras técnicas para mantener micro-frontends sincronizados. Pero, ¿cómo manejas la gestión de estado compartido? Tuvimos esto en Rayway 42 porque teníamos una aplicación Angular comunicándose con una aplicación React que vivía dentro de ella. Y fue muy, muy fácil, en realidad. No experimentamos mucho sobrecargo alrededor de eso. Teníamos un objeto global, que estaba comunicando entre los servicios Angular y nuestros estados React. No era Redux, por lo que era algo completo y con datos. Y sí, diría que el problema es más exagerado de lo que realmente es.

Esa es una perspectiva realmente buena, también, porque asumiría que es absolutamente enorme, no poder compartir el estado. Pero como lo has hecho unas cuantas veces a gran escala, saber que en realidad no ha sido tanto un problema es una visión realmente útil. Nos hemos quedado sin tiempo. Una vez más, hay una sección de preguntas y respuestas con el orador, un área de preguntas y respuestas con el orador, que está cerca de la recepción. Vaya, la gente se está moviendo rápido.

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
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
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 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.
React Summit 2022React Summit 2022
25 min
React Microfrontend Applications for TVs and Game Consoles
DAZN is the fastest-growing sports streaming service and during this talk, we will consider our experience building tv applications (for ps5, xbox, LG, Samsung and other targets) with micro frontend architecture. You may expect time travel to see how it started and what we have at the moment, what makes tv development different compared to the web, same as techniques that allow us to share code between targets. You will learn how we test our application with an in-house remote testing lab as well as our deployment and release process.

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.