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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.