La Revolución de Micro-Frontends en Amex

Hola a todos. Me llamo Ruben y soy ingeniero de software en American Express. Y hoy voy a hablar sobre la revolución de micro frontends que tuvo lugar en American Express.

Así que, primero que nada, comencemos con una historia. Imaginemos que acabas de ser contratado como el nuevo CTO de esta gran, gran corporación. Así que eres responsable de la transformación digital de la empresa, así como de solucionar problemas con la escalabilidad. Y estás a cargo de solucionar estos problemas.

Entonces, la primera decisión que tomas es, bien, necesitamos más desarrolladores. Necesitamos agregar más personas, y eso es lo que haces. Así que, también eres fan de la regla de las dos pizzas, y piensas, bien, necesitamos crear equipos más pequeños y agregar esos desarrolladores a esos equipos. Así que creamos equipos autónomos más pequeños, y porque en el pasado, fuiste parte de esta empresa anterior y tuviste algo de experiencia previa, piensas, oh, creo que deberíamos hacer arquitectura de microservicios aquí. Es una buena idea. Está comprobado. Hay muchos recursos disponibles, y es ampliamente adoptado.

Así que, aprovechemos al máximo la arquitectura de microservicios, y aprovechemos al máximo la escalabilidad horizontal, porque sabemos que la escalabilidad vertical no es suficiente en algún momento, así que queremos comenzar a hacer escalabilidad horizontal. Y eso es genial. Eso está funcionando muy bien. Hasta que, bueno, hasta que intentamos aplicar estos métodos al frontend. ¿Y qué pasa con el frontend? Bueno, el frontend, imaginemos que este frontend es una aplicación monolítica realmente grande. Tiene mucho código heredado. Todos los ingenieros están trabajando en la misma base de código. Y si queremos agregar más ingenieros, obviamente esto es una mala idea, porque están trabajando en la misma base de código. Entonces, cuantos más ingenieros agregues, peor se vuelve, porque será simplemente una pesadilla gestionar a tantas personas trabajando en la misma base de código.

Así que el frontend tiene muchos desafíos. Y estos desafíos son problemas de comunicación, fricción, lleva más y más tiempo agregar nuevas funciones, arreglar y encontrar errores se convierte en un desafío, muy difícil mantener los entornos de producción y desarrollo sincronizados. Y en algún momento de nuestras carreras, todos hemos tenido esta pregunta. Todos estábamos, como, ¿qué tal una reescritura completa? Y piensas, oh, ¿es eso siquiera posible? Parece una tarea muy, muy difícil. Parece una tarea imposible. Pero estás considerando, bien, necesitamos hacer una reescritura completa. Ahora, pero espera un segundo.

Creo que hemos visto estos problemas antes. Hemos visto todos estos problemas de comunicación, todo esto. Tuvimos esto cuando estábamos adoptando microservicios. Así que pensamos, hmm, ¿qué necesitamos hacer para aplicar los microservicios al frontend para resolver estos problemas?

Así que lo primero que intentas es, bueno, he visto esta cita en algún lugar. La entrega independiente podría ser un verdadero punto de inflexión para que las grandes organizaciones permitan a sus equipos entregar más rápido y libremente y colaborar de manera más efectiva. Y piensas, bueno, eso es. Necesito permitirles desplegar independientemente. Quiero permitirles entregar independientemente para que no trabajen en la misma base de código y puedan entregar independientemente. Y ese es nuestro primer enfoque. Y tratamos de dividir el frontend y digamos que vamos a dividirlo en subdominios.

Así que, le damos a cada equipo un subdominio y ellos van a construir la aplicación en ese subdominio y todos deberían estar contentos con eso y nosotros resolveremos muchos problemas. Bueno, en realidad, tener solo entrega independiente podría causar más problemas y más desafíos que soluciones reales. Y permíteme expandir sobre eso.

Por qué esto causará más desafíos. Bueno, si le damos a las personas su propio subdominio o su propio lugar en el sitio web, los equipos tenderán a comenzar a construir aplicaciones en silos. ¿Y qué es un silo? Bueno, es una forma de construir software que es muy difícil de comunicar con otra pieza de software. Así que, la aplicación y las características se construyen en silos, y comenzamos a ver a las personas haciendo lo suyo. Ahora, eso también causa experiencias de usuario fragmentarias. Porque están usando sus propias herramientas y están siguiendo lo suyo, y simplemente no les importa comunicarse con otros equipos. Terminamos con una experiencia de usuario muy disgregada donde el sitio web podría verse muy diferente si vas a un subdominio o si vas a un subdominio diferente del sitio web, cuando estás transfiriendo, espera un minuto, el sitio web no se ve igual, y comienza a verse muy diferente.

Ahora, si también comenzamos a construir la misma funcionalidad una y otra vez, por ejemplo, si queremos construir una variación diferente o si quieres traducir esa página a un idioma diferente o lanzar un mercado diferente en un lugar diferente, terminamos construyendo la misma funcionalidad una y otra vez solo porque tiene algunas variaciones en el idioma o diferentes regulaciones en diferentes partes del planeta. Así que, comenzamos a construir lo mismo una y otra vez. No hay reutilización. Además, porque es realmente difícil de actualizar y gestionar, las cosas están por todas partes y es muy difícil tener un lugar donde actualizar algo en un lugar que se propague por todo el sitio web. Esto es realmente molesto para mí cuando tienes problemas de autenticación y estás en un sitio web y te pide que inicies sesión nuevamente. Pero espera, acabo de iniciar sesión en esta parte del sitio web y me está pidiendo que inicie sesión nuevamente. Así que, terminamos con muchos problemas de autenticación y autenticación persistente. Ahora, esta es la gran pregunta. Esta es una gran pregunta en esta presentación. ¿Cómo escalamos una aplicación web para ser desarrollada no solo por cientos, sino por miles de ingenieros y actualizarla para usar las últimas tecnologías? Es una pregunta muy cargada.

Y esto es lo que queremos intentar resolver. Esto es lo que queremos lograr. Así que, permíteme decirte, redoble de tambores, ¿cuál es la solución? Bueno, esta es una solución. Aplicar micro frontends. Un micro frontend es solo una forma de aplicar el patrón de arquitectura de microservicios al frontend. Y es un conjunto de herramientas que nos permitirá hacer eso y solucionar todos esos desafíos y problemas que enfrentamos.

Entonces, ¿cómo lo hacemos? Un poco de historia. American Express es de hecho un pionero en la implementación de micro frontends. Y desde 2016, hemos implementado este framework que nos permite crear micro frontends renderizados del lado del servidor y componerlos en la página. Así que, este framework resuelve muchos de estos problemas. Y voy a hablar un poco sobre cómo este framework y cómo el concepto detrás del framework ha ayudado a American Express a resolver los problemas de escalabilidad. Así que, echemos un vistazo.

En primer lugar, ¿qué hemos resuelto y qué características nos han ayudado a resolver algunos de los problemas? Bien. Comencemos por el diseño modular por defecto. ¿Qué quiero decir con diseño modular? Bueno, estamos construyendo en lugar de páginas enteras o aplicaciones enteras, estamos construyendo módulos. Y estos módulos nos permiten desplegarlos independientemente, pero también podemos dar partes del sitio web, no solo el subdominio, solo partes muy granulares del sitio web a equipos independientes. Un ejemplo de esto sería que hay un equipo que maneja el encabezado y el pie de página y la navegación general. Esa navegación general, el equipo se encargará de asegurarse de que esté traducida a todos los idiomas, se asegurarán de que tenga la última versión, los últimos colores, los últimos enlaces y todo. Y probablemente también tengamos otro equipo manejando la autenticación. Si soy uno de los equipos desarrollando una página, sé que no tengo que preocuparme por el encabezado o el pie de página o los nuevos enlaces que deben ser añadidos, porque puedo simplemente arrastrar y soltar ese módulo en mi página y luego continuar con mi desarrollo. Lo mismo con la autorización de autenticación. No tengo que preocuparme por implementar la autenticación muchas veces porque sé que hay un módulo que permite hacer autenticación. Esto también proporciona renderizado del lado del servidor y esta aplicación nos permite no solo experiencias interactivas del lado del cliente, sino también renderizar nuestras aplicaciones del lado del servidor, lo cual es importante para el SEO. También nos proporciona seguridad empresarial. Es muy importante que gestiones eso desde un lugar centralizado y te asegures de que todos cumplan con la seguridad. Implementar cosas como la política de seguridad de contenido, que es un estándar de la industria, asegurando que cada módulo proporcione la seguridad requerida. Si recuerdas antes, mencioné cuando intentas hacer diferentes mercados o internacionalización, la aplicación proporciona esa opción para traducir esos módulos y simplemente reutilizarlos en diferentes contextos. La característica principal de todas, como discutimos antes, es permitir despliegues independientes. Cada equipo tendrá su propia capacidad para desplegar a producción sin tener que desplegar todo el sitio web, toda la aplicación. Y lo más importante de todo, no hay reinicio del servidor.

Así puedes desplegar de manera independiente. No tienes que reiniciar ningún servidor cuando despliegas. El servidor simplemente seguirá funcionando. Y probablemente es cuando empiezas a preguntar, está bien, muéstrame la arquitectura, muéstrame el código, muéstrame qué hay detrás de escena de este framework. Bien. Entonces, vamos a ver la tecnología detrás de esto. Y la tecnología es básicamente tenemos un servidor Node.js en el fondo que es solo un servidor de larga ejecución. Ese servidor proporciona el renderizado del lado del servidor, proporciona la composición de diferentes módulos.

Y en el lado derecho, tenemos los módulos Holocron que son básicamente micro frontends construidos sobre React. Sí, referencia a Star Wars. Nos gusta Star Wars y módulos Holocron es el nombre que hemos dado a los módulos y los micro frontends. Y estos módulos están a cargo de la lógica de negocio. Están a cargo de la experiencia del usuario. Así que, no hay lógica de negocio ni nada está construido en el servidor Node.js. El servidor Node.js es solo el orquestador. Es solo el contenedor que está a cargo del renderizado del lado del servidor y la descomposición. Pero toda la lógica y todas las aplicaciones están construidas como módulos Holocron independientes. Y estamos usando React para permitir este modelo de composición.

Ahora echemos un vistazo al diagrama y qué sucede cuando estamos en producción. Entonces, en producción, tenemos, nuevamente, el servidor Node.js es el proceso de larga ejecución. Y tenemos nuestros módulos Holocron desplegados en un CDN. Esos módulos en el CDN están desplegados y tienen los activos estáticos, el código del servidor, así como el código del cliente. Y la forma en que sabemos qué módulos están desplegados en la aplicación particular en la que estamos trabajando es usando algo que llamamos el mapa de módulos. El mapa de módulos es solo un archivo JSON que es muy similar. Puedes pensar en el mapa de módulos como algo parecido al archivo package.json donde tenemos una referencia, una lista de módulos y sus versiones y qué módulos deberían estar activos en esta aplicación. Entonces, lo que hace el servidor 1Up es seguir verificando este archivo JSON regularmente para cambios y descubrirá si un módulo ha sido actualizado, si ha sido eliminado o si ha sido añadido. Y esos módulos se añaden a la memoria. Esos módulos en memoria están listos para ser renderizados y para recibir solicitudes. Así que, después de que los módulos se cargan en memoria, cuando el usuario escribe la URL, la solicitud llegará al servidor one app y luego tendremos los módulos compuestos en la página.

También puedes cargar diferentes módulos en diferentes URLs y componerlos, depende del desarrollador y de sus requisitos cómo componer esos módulos en la página. Correcto. Así que esto es más o menos lo que sucede en la producción.

Ahora, la mayoría de nosotros somos desarrolladores. Veamos. ¿Cómo gestionas esto en el desarrollo? Porque la primera pregunta que podríamos tener es, bien, tenemos digamos 300 módulos en producción. ¿Cómo se supone que debo usar todo este código? ¿Cómo se supone que debo descargar este código y hacer un cambio? Bueno, cada módulo tiene su propio repositorio. Tienen su propio pipeline de CI y están aislados.

Así que tienen su propia base de código. Entonces, la forma en que hacemos esto es que tenemos un entorno de desarrollo local que extraerá el servidor 1-up de una imagen de Docker. También tenemos un CDN localmente. Entonces, lo que sucede es que si quiero hacer un cambio en uno de los módulos, simplemente clono el repositorio en mi máquina local, hago el cambio, y el servidor 1-up localmente desde Docker cargará todos los demás módulos que están en producción y los compondrá para mi aplicación. Así que no tengo que descargar todo el código. Puedo simplemente descargar el módulo que quiero cambiar, componerlo localmente, probarlo, y luego estará listo para el despliegue.

Así que esto es lo que sucede en el desarrollo. Es una forma muy fácil de gestionar bases de código separadas. Y, nuevamente, el pipeline de CICD y todo es individual para cada módulo. Así que, después de que he hecho los cambios en mi módulo, haré pruebas unitarias independientes. También realizaré algunas pruebas de integración para asegurarme de que el módulo se comporte como se espera cuando se ejecuta en el entorno con los otros módulos, y luego lo enviaré. Después de enviarlo a producción, el pipeline de CICD lo publicará en el CDN de producción, y luego el observador de producción lo extraerá del mapa de módulos y se instalará una nueva versión. Todo sucede en tiempo de ejecución. El observador no necesita reiniciarse cuando se añade un nuevo módulo a la memoria. Simplemente encontrará un nuevo módulo, lo pondrá en memoria, y luego tendrás algo en producción. Esto es muy poderoso porque significa que no tienes que preocuparte por desplegar cosas y reiniciar servidores y tiempos de inactividad, porque el servidor siempre está funcionando y los módulos pueden ser simplemente añadidos y eliminados en tiempo de ejecución.

Bien. Así que esta es solo una conclusión. Y la conclusión es, bueno, esto es genial. Esto ha funcionado muy bien para nosotros. Los microfrontends han sido una arquitectura que ha resuelto muchos problemas con el escalado, asegurando que podamos tener miles de desarrolladores trabajando en la misma aplicación sin tener muchos problemas con bases de código únicas y muchos problemas con los despliegues. Pero la conclusión es, no hay un enfoque único.

No hay una solución única para este problema. Los microfrontends son un patrón. No son un conjunto de herramientas o un framework que se pueda simplemente conectar y usar. Depende de tu caso de uso. Y tu caso de uso específico probablemente impulsará los requisitos y la arquitectura que necesitas usar para resolver los problemas de escalado.

Así que, diferentes empresas tendrán diferentes problemas y tendrás diferentes cosas que puedes resolver. Así que, solo para concluir, el framework one up es de código abierto si quieres echarle un vistazo y solo háznos saber qué piensas.

Así que, sí, muchas gracias. Y espero que hayas disfrutado de tu presentación. Ahora solo espero que tengas algunas preguntas. ¿Qué piensas? ¿Deberían los micro frontends usar un solo lenguaje de framework o tener múltiples? Parece que la mayoría piensa en uno solo. ¿Qué piensas de eso?

Bueno, esa fue una gran pregunta. Porque la cuestión con los micro contenidos es que la gente piensa que se trata de mezclar frameworks. Y eso no es cierto. Eso no es de lo que tratan los microfrontends. Deberías usar uno. Quiero decir, puedes usar múltiples frameworks. Y hay un caso de uso válido. Digamos que la aplicación está construida en Angular JS y quieres actualizarla a React. Entonces podrías usar microfrontends para hacer la actualización, como el patrón straggler, que es actualizar la aplicación de manera incremental. Pero al final, no creo que sea recomendable por problemas de rendimiento. Quiero decir, podrías. Y he escuchado a personas decir que le dieron a los desarrolladores la flexibilidad de usar el framework que querían usar. Y al final, terminaron usando solo un framework porque es el que con el que se sienten más cómodos. Así que, sí. Sí, sí, sí. También tienes que pensar en el... Yo pensaría que tendrías que pensar en el costo del equipo, ya sabes. Cuesta mucho más tener un desarrollador que conozca todos estos frameworks que tener uno que tal vez sea específico de uno solo. Sí.

Ese es un punto. Tenemos algunas preguntas de nuestra audiencia, nuestra encantadora audiencia. El Dr. Jessie Pye preguntó, ¿NestJs se adapta a mis front ends actuales? NestJs. Bueno, probablemente necesitemos hablar con ellos sobre este tema. Nest, lo siento. Sí. Lo siento. Me perdí la pregunta. Bueno, la cuestión es que adoptar un patrón de Microfrontend en un framework existente es un desafío porque es completamente una forma de construir arquitectura. Y la característica clave de Microfrontend para permitir que cualquier framework use este patrón es permitir la entrega independiente para que puedas implementar partes de la aplicación de manera independiente sin tener que reiniciar la aplicación completa. Así que es posible con cualquier framework, la cuestión es, ya sabes, tiene que ser reestructurado para permitir implementaciones independientes. Y características como Webpack, Module Federation podrían ayudar con eso. Entendido.

Eso en realidad nos lleva a nuestra siguiente pregunta de Maxim Leont. ¿Cómo resuelves problemas con la comunicación de módulos? Y Danji también preguntó cómo se comunican los módulos entre sí. Bien. Entonces, la comunicación es que puedes elegir qué mecanismos de comunicación deseas usar, pero lo principal que debes tener en cuenta es que los módulos deben permanecer lo más independientes posible. Así que no es un desarrollo de aplicación tradicional donde simplemente pasas datos en cascada o usando props. Con micro frontends es muy importante mantener su independencia para que carguen los datos que necesitan y no dependan de otros micro frontends y no estén fuertemente acoplados entre sí. Eso es muy importante con los micro frontends. Ahora, hay casos obvios donde eso no es posible y necesitas enviar comunicación y necesitas actualizar otros micro frontends dependiendo del estado de otros micro frontends. Así que en ese punto puedes elegir tu mecanismo. Puedes usar simplemente enviar eventos, esa es una solución. Otras personas prefieren usar una gestión de estado como gestión de estado global como Redux, por ejemplo, pero compartir un estado también es un poco difícil. Es muy importante que no acoples fuertemente esos micro frontends, por lo que depende de tu implementación. Pero de nuevo, muy importante, no los acoples.

Sí, eso suena como que se va a volver complicado si están demasiado acoplados. David Liam pregunta si tienes alguna recomendación sobre cómo un equipo de microservicios con UI para cada servicio migraría a micro frontends.

De hecho, ese es el mejor lugar para comenzar a considerar una arquitectura de micro frontends. Así que si tu empresa ya está usando microservicios, tienes aplicaciones a gran escala y estás usando Kubernetes, y tienes muchos equipos distribuidores que poseen su propia parte del producto, es un muy buen lugar para comenzar a implementar micro frontends porque en ese punto, puedes comenzar una división de dominio de tu aplicación, donde puedes simplemente dar al equipo la responsabilidad de esa parte. Y ellos serán responsables del backend y del front end. Y también hay una nueva tendencia, que es backends para front ends, donde el microservicio de backend estará a cargo de proporcionar la información solo a un front end. Y si sigues el patrón de micro frontends, entonces eso será más fácil, porque significa que el equipo puede poseer la totalidad de ese producto o experiencia.

Eso es realmente interesante. Se relaciona con la pregunta de Andre Calisson. Has mencionado que el equipo puede poseer el front end, el backend. Andre tiene curiosidad sobre la infraestructura. Así que pregunta, ¿cómo es la composición de los equipos en Amex? Dijiste que cada modelo tiene su propia pipeline de CI-CD. ¿También son responsables de mantener estas infraestructuras? ¿Cómo se ve cuando se forma un nuevo equipo? ¿Cómo comienzan con su propio módulo?

Correcto. Así que la infraestructura es algo que es gestionado por otros equipos, pero obtenemos todo configurado por defecto. Así que cuando comienzas un nuevo micro frontend, obtendrás tu propio repositorio y hay algo de automatización para crear infraestructura para ello. Así que podrías crear algo de automatización para agregar todos los trabajos que se requieren para el despliegue de esos micro frontends. Así que es parte de la incorporación de infraestructura y con algo de buena automatización, es algo que es muy fácil de gestionar, por lo que no tienes que preocuparte por comenzar desde cero. Cada vez que creas un nuevo micro frontend, todo vendrá listo para usar.

Eso es increíble y probablemente ayuda con la velocidad del equipo para que haya menos costo de sobrecarga cuando comienzas, ¿verdad?

Sí, eso es correcto. Así que no necesitas preocuparte por la infraestructura, solo necesitas crear tu micro frontend, desplegarlo y luego todo se desplegará en los diferentes entornos. Eso es tan agradable. Quiero eso.

Sí. Tenemos otra pregunta. De hecho, tenemos toneladas de preguntas. A la gente le encanta esta charla, bien hecho. House of Alejandro preguntó, dice, presentación increíble. De acuerdo. Y también pregunta, ¿qué piensas sobre los micro frontends sin renderizado del lado del servidor? ¿Sería tan buena solución como un enfoque de renderizado del lado del servidor? Bueno, el renderizado del lado del servidor es algo que añadimos a nuestros micro frontends, pero no significa que tengas que hacerlo. Y encontrarás la respuesta a esa pregunta es, ¿necesitas renderizado del lado del servidor en tu aplicación? Así que si tienes una aplicación renderizada del lado del cliente que hace el trabajo y no tienes que preocuparte por el SEO o algo así, de nuevo, las reglas que se aplican cuando eliges renderizado del lado del servidor o del lado del cliente se aplican en el mismo caso. La única diferencia es que esas aplicaciones se despliegan de manera independiente.

Así que es bueno que, en nuestro framework, tengamos renderizado del lado del servidor, pero también las aplicaciones solo del lado del cliente con micro frontends definitivamente serán más fáciles. Eso es algo a tener en cuenta. El renderizado del lado del servidor también añade algo de complejidad. Así que si es solo una SPA, como una aplicación de una sola página, solo del lado del cliente, eso también funcionaría. Genial. Sí.

Así que William preguntó y tenemos esta es una pregunta final muy corta. Así que sin presión. ¿Viste un gran aumento en el tamaño de descarga al adoptar micro frontends? Puedo imaginar que todos esos módulos traen todo tipo de dependencias. ¿Cómo lo resolviste? Esta es una gran pregunta. Así que tenemos un límite. Así que 250K para micro frontend como base. Y la forma en que logras eso, para que el tamaño del bundle no esté inflado, es usando una combinación de webpack externals y combinación de importación dinámica. Así que puedes lograr un tamaño de bundle más pequeño. Pero eso es lo principal que queremos asegurarnos de que no sean demasiado grandes. Esa es una buena regla. Qué gran pregunta.

Muchas gracias a todas las personas que hicieron preguntas. Ruben, quedan un par de preguntas si quieres entrar en Discord y darles una respuesta. Y demos todos un gran aplauso virtual a Ruben.