La Revolución de los Micro Frontends en Amex

Rate this content
Bookmark

¿Cómo escalas una aplicación web para ser desarrollada por miles de ingenieros y actualizarla para utilizar las últimas tecnologías de JavaScript (Node.js + React)? ¡La respuesta es utilizando Micro Frontends!

American Express es pionero en el uso de esta arquitectura, utilizándola en producción desde 2016 y transformando la cara de un sitio web utilizado por millones de usuarios en todo el mundo.

28 min
24 Jun, 2021

Video Summary and Transcription

Esta charla discute la revolución de los micro frontends en American Express, destacando los desafíos de la entrega independiente y la solución de los micro frontends. La arquitectura involucra un servidor Node.js para renderizado en el lado del servidor y composición de módulos, con módulos Holocron desplegados en un CDN. El flujo de trabajo de desarrollo incluye entornos de desarrollo locales y tuberías de integración continua. Los micro frontends son un patrón, no un conjunto de herramientas, y deben implementarse en función del caso de uso específico. Los desafíos de adopción incluyen la reestructuración de la arquitectura e implementación de características como Webpack y Module Federation. La comunicación entre módulos debe mantenerse independiente y la migración a micro frontends se simplifica con microservicios y Kubernetes existentes. El renderizado en el lado del servidor es opcional y el tamaño del paquete está limitado a 250K.

Available in English

1. Introducción a la Revolución de los Micro Front-End

Short description:

Hola a todos. Mi nombre es Rubén y soy un ingeniero de software en American Express. Hoy voy a hablar sobre la revolución de los micro front-end que tuvo lugar en American Express. Comencemos con una historia. Imagina que acabas de ser contratado como el nuevo CTO de una gran corporación, responsable de la transformación digital y la escalabilidad. Decides agregar más desarrolladores y crear equipos autónomos más pequeños. Sin embargo, aplicar estos métodos al frontend presenta desafíos debido a una gran aplicación monolítica con código heredado. Surgen problemas de comunicación, fricción y dificultades para agregar nuevas características. Una reescritura completa parece desalentadora, pero detengámonos por un momento.

Y hoy voy a hablar sobre la revolución de los micro front-end que tuvo lugar en American Express. Así que, en primer lugar, comencemos con una historia. Imaginemos que acabas de ser contratado como el nuevo CTO de esta gran corporación. Entonces, eres responsable de la transformación digital de la empresa, así como de solucionar problemas de escalabilidad. Y estás a cargo de solucionar estos problemas.

La primera decisión que tomas es, ¿verdad?, necesitamos más desarrolladores. Necesitamos agregar más personas, y eso es lo que haces. También eres fan de la regla de las dos pizzas, y piensas, ¿verdad?, 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 como en el pasado, fuiste parte de esta empresa anterior y tenías cierta experiencia previa, piensas, oh, creo que deberíamos hacer una arquitectura de microservicios aquí. Es una buena idea. Ha sido probada. Hay muchos recursos disponibles y es ampliamente adoptada. 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 funciona muy bien. Hasta que, bueno, hasta que intentamos aplicar estos métodos al frontend. ¿Y qué sucede 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 el mismo código base. Y si queremos agregar más ingenieros, obviamente esto es una mala idea, porque están trabajando en el mismo código base. Entonces, cuanto más ingenieros agregas, peor se vuelve, porque será una pesadilla administrar a tantas personas trabajando en el mismo código base.

Entonces, el frontend tiene muchos desafíos. Y estos desafíos son problemas de comunicación, fricción, cada vez lleva más tiempo agregar nuevas características, solucionar 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 nos hemos preguntado, ¿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, ¿verdad?, que necesitamos

2. Desafíos de la Entrega Independiente

Short description:

Creo que hemos visto estos problemas antes. Los tuvimos cuando estábamos adoptando microservicios. La entrega independiente podría ser un punto de inflexión para las grandes organizaciones para permitir que los equipos entreguen más rápido y colaboren de manera más efectiva. Sin embargo, dividir el frontend en subdominios y permitir la entrega independiente puede causar más desafíos que soluciones. Construir aplicaciones en silos conduce a experiencias de usuario fragmentadas y la necesidad de duplicar funcionalidades. La actualización y gestión se vuelve difícil, lo que resulta en problemas de autenticación. Escalar una aplicación web para ser desarrollada por miles de ingenieros y adoptar las últimas tecnologías es una pregunta complicada.

Hacer una reescritura completa. Pero espera un segundo. Creo que hemos visto estos problemas antes. Hemos visto todos estos problemas de comunicación, todas estas cosas. Los tuvimos cuando estábamos adoptando microservicios. Entonces pensamos, hmm, ¿qué necesitamos hacer para aplicar los microservicios al frontend y resolver estos problemas? Lo primero que intentas es, bueno, he visto esta cita en algún lugar. La entrega independiente podría ser un punto de inflexión para las grandes organizaciones para permitir que sus equipos entreguen más rápido y libremente y colaboren de manera más efectiva. Y piensas, bueno, eso es. Necesito permitirles implementar de forma independiente. Quiero permitirles entregar de forma independiente para que no trabajen en el mismo código base y puedan entregar de forma independiente. Ese es nuestro primer enfoque. Intentamos dividir el frontend y digamos que lo vamos a dividir en subdominios. Entonces, le damos a cada equipo un subdominio y van a construir la aplicación en ese subdominio y todos deberían estar contentos con eso y resolveremos muchos problemas. Bueno, en realidad, tener solo entrega independiente podría causar más problemas y desafíos que soluciones reales. Permíteme expandirme en eso. ¿Por qué esto causará más desafíos? Bueno, si les 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. Entonces, la aplicación y las características se construyen en silos, y comenzamos a ver a las personas haciendo su propia cosa. Ahora, eso también causa experiencias de usuario fragmentadas. Debido a que están utilizando sus propias herramientas y siguen su propio camino, simplemente no les importa comunicarse con otros equipos. Terminamos con una experiencia de usuario muy desarticulada donde el sitio web puede verse muy diferente si vas a un subdominio o si vas a un subdominio diferente del sitio web, cuando estás navegando, 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. Entonces, comenzamos a construir lo mismo una y otra vez. No hay reutilización. Además, debido a que es realmente difícil actualizar y gestionar, las cosas están por todas partes y es muy difícil tener un lugar para actualizar algo en un solo 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. Entonces, 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 complicada.

3. Micro Frontend Solution

Short description:

Aplicar micro frontends es una solución para solucionar los desafíos y problemas enfrentados al implementar la entrega independiente. American Express ha sido un pionero en este enfoque desde 2016, utilizando un marco que permite la creación de micro frontends renderizados en el lado del servidor. Este marco permite un diseño modular, implementaciones independientes, renderizado en el lado del servidor, seguridad empresarial y fácil internacionalización. La ventaja clave es la capacidad de cada equipo para implementar sus propios cambios sin reiniciar el servidor.

Una pregunta muy cargada. Y esto es lo que queremos intentar resolver. Esto es lo que queremos lograr. Permítanme decirles, redoble de tambores, ¿cuál es la solución? Bueno, esta es una solución. Aplicar micro frontends. Un micro frontend es simplemente 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 a los que nos enfrentamos. Entonces, ¿cómo lo hacemos? Un poco de historia. American Express es en realidad un pionero en la implementación de micro frontends. Y desde 2016, hemos implementado este marco que nos permite crear micro frontends renderizados en el lado del servidor y componerlos en la página. Entonces, este marco resuelve muchos de estos problemas. Y voy a hablar un poco sobre cómo este marco y el concepto detrás del marco han ayudado a American Express a resolver los problemas de escalabilidad. Echemos un vistazo. Primero que nada, ¿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, en lugar de construir páginas completas o aplicaciones completas, estamos construyendo módulos. Y estos módulos nos permiten implementarlos de forma independiente, pero también podemos dar partes del sitio web, no solo el subdominio, partes muy granulares del sitio web a equipos independientes. Un ejemplo de esto sería un equipo que se encarga del encabezado y el pie de página y la navegación general. Ese equipo se encargará de asegurarse de que se traduzca 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 que se encargue de la autenticación. Si soy uno de los equipos que desarrolla una página, sé que no tengo que preocuparme por el encabezado o el pie de página o los enlaces más nuevos que se deben agregar, porque simplemente puedo arrastrar y soltar ese módulo en mi página y luego seguir con mi desarrollo. Lo mismo ocurre con la autenticación y autorización. No tengo que preocuparme por implementar la autenticación muchas veces porque sé que hay un módulo que permite hacerlo. Esto también proporciona renderizado en el lado del servidor y esta aplicación nos permite no solo experiencias interactivas del lado del cliente, sino también renderizar nuestras aplicaciones en el lado del servidor, lo cual es importante para el SEO. También nos proporciona seguridad empresarial. Es muy importante que administres eso desde un lugar centralizado y te asegures de que todos cumplan con la seguridad. Implementa cosas como la política de seguridad de contenido, que es un estándar de la industria, simplemente asegurando que cada módulo proporcione la seguridad requerida. Si recuerdas antes, mencioné que cuando intentas hacer diferentes mercados o internacionalización, la aplicación proporciona esa opción de traducir esos módulos y reutilizarlos en diferentes contextos. La característica principal de todas, como discutimos antes, es permitir implementaciones independientes. Cada equipo tendrá su propia capacidad para implementar en producción sin tener que implementar todo el sitio web, toda la aplicación. Y lo más importante de todo, no hay reinicio del servidor.

4. Micro Frontend Architecture

Short description:

Para que puedas implementar de forma independiente. El servidor Node.js proporciona renderizado en el lado del servidor y composición de módulos. Los módulos Holocron, construidos sobre React, manejan la lógica empresarial y la experiencia del usuario. El servidor Node.js es solo el orquestador. En producción, los módulos Holocron se implementan en un CDN con activos estáticos, código de servidor y código de cliente. El archivo JSON del mapa de módulos determina qué módulos están activos. El servidor 1Up verifica el mapa de módulos en busca de cambios y carga los módulos en memoria. Cuando un usuario escribe la URL, los módulos se componen en la página.

Para que puedas implementar de forma independiente. No tienes que reiniciar ningún servidor cuando implementas. El servidor simplemente seguirá funcionando. Y probablemente en este momento te estés preguntando, bien, muéstrame la arquitectura, muéstrame el código, muéstrame qué hay detrás de escena de este marco. Bueno. Así que vamos a ver la tecnología detrás de esto. Y la tecnología es básicamente que tenemos un servidor Node.js en segundo plano que es simplemente un servidor en ejecución continua. Ese servidor proporciona el renderizado en el lado del servidor, proporciona la composición de diferentes módulos.

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

Ahora veamos el diagrama y qué sucede cuando estamos en producción. En producción, nuevamente tenemos el servidor Node.js como el proceso en ejecución continua. Y tenemos nuestros módulos Holocron implementados en un CDN. Esos módulos en el CDN se implementan y tienen los activos estáticos, el código de servidor y el código de cliente. Y la forma en que sabemos qué módulos se implementan en la aplicación específica en la que estamos trabajando es mediante el uso de algo que llamamos el mapa de módulos. El mapa de módulos es simplemente un archivo JSON que es muy similar. Puedes pensar en el mapa de módulos como algo similar al archivo package.json donde tenemos una referencia, una lista de módulos y sus versiones y qué módulos deben estar activos en esta aplicación. Entonces, lo que hace el servidor 1Up es verificar regularmente este archivo JSON en busca de cambios y descubrirá si se ha actualizado un módulo, si se ha eliminado o se ha agregado. Y esos módulos se agregan a la memoria. Esos módulos en memoria están listos para ser renderizados y para recibir solicitudes. Entonces, después de que los módulos se cargan en memoria, cuando el usuario escribe la URL, la solicitud llegará al servidor 1Up y luego tendremos los módulos compuestos en la página. Entonces, si observas el diagrama a continuación, tenemos el módulo raíz, que básicamente es el módulo donde configuramos la aplicación y contiene los otros módulos y luego tenemos

5. Development Workflow and Conclusion

Short description:

Puedes cargar diferentes módulos en diferentes URL y componerlos según tus necesidades. En desarrollo, cada módulo tiene su propio repositorio y canalización de CI. Un entorno de desarrollo local extrae el servidor 1-up y los módulos de Docker. Se pueden realizar cambios en módulos específicos, componerlos localmente y probarlos antes de implementarlos. La canalización de CI/CD se encarga de las pruebas unitarias e de integración, la publicación en el CDN de producción y la actualización del mapa de módulos en tiempo de ejecución. Los microfrontends han resuelto problemas de escalabilidad e implementación, pero no hay un enfoque único.

Puedes cargar diferentes módulos individuales en la misma página. También puedes cargar diferentes módulos en diferentes URL y componerlos, depende del desarrollador y de sus necesidades cómo componer esos módulos en la página. Entonces, esto es más o menos lo que sucede en producción. Ahora, la mayoría de nosotros somos desarrolladores. Veamos. ¿Cómo se gestiona esto en 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 propia canalización de CI y están aislados. Entonces, tienen su propia base de código. 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 local desde Docker cargará todos los demás módulos que están en producción y los compondrá para mi aplicación. Entonces, no tengo que descargar todo el código. Solo puedo descargar el módulo que quiero cambiar, componerlo localmente, probarlo y luego estará listo para implementarse. Entonces, esto es lo que sucede en desarrollo. Es una forma muy fácil de gestionar bases de código separadas. Y, nuevamente, la canalización de CI/CD y todo es individual para cada módulo. Entonces, después de haber realizado los cambios en mi módulo, realizaré 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 implementaré. Después de implementarlo en producción, la canalización de CI/CD lo publicará en el CDN de producción y luego el observador de producción extraerá ese módulo del mapa de módulos y se instalará una nueva versión. Todo sucede en tiempo de ejecución. El observador solo necesita encontrar un nuevo módulo, ponerlo en memoria y luego tienes algo en producción. Entonces, esto es muy poderoso porque significa que no tienes que preocuparte por implementar cosas y reiniciar servidores y tiempo de inactividad, porque el servidor siempre está en funcionamiento y los módulos se pueden agregar y eliminar en tiempo de ejecución. Ok. Entonces, 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 de escalabilidad, asegurándose de 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 implementaciones.

QnA

Microfrontend Patterns

Short description:

No hay una solución única para este problema. Los microfrontends son un patrón. No son un conjunto de herramientas o un marco en el que se puedan enchufar y usar. Depende de tu caso de uso. Diferentes empresas tendrán diferentes problemas y tendrás diferentes cosas que puedes resolver. ¿Deberían los micro frontends usar un solo lenguaje de marco o varios? Parece que la mayoría piensa en uno solo. La cosa con los micro contenidos es que la gente piensa que se trata de mezclar marcos. Y eso no es cierto. Deberías usar uno. Quiero decir, puedes usar varios marcos. Pero al final, no creo que sea recomendable por problemas de rendimiento. También tienes que pensar en el costo del equipo, ya sabes. Cuesta mucho más tener un desarrollador que conozca todos estos marcos que tener uno que tal vez sea específico para uno solo.

Pero la conclusión es que 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 marco en el que se puedan enchufar y usar. Depende de tu caso de uso. Y tu caso de uso específico probablemente determinará los requisitos y la arquitectura que necesitas usar para resolver los problemas de escalabilidad.

Diferentes empresas tendrán diferentes problemas y tendrás diferentes cosas que puedes resolver. Entonces, solo para concluir, el marco one up es de código abierto si quieres echarle un vistazo y hacernos saber qué piensas. Entonces, 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 marco o varios? Parece que la mayoría piensa en uno solo. ¿Qué opinas de eso?

Bueno, esa fue una gran pregunta. Porque la cosa con los micro contenidos es que la gente piensa que se trata de mezclar marcos. Y eso no es cierto. Eso no es de lo que se tratan los microfrontends. Deberías usar uno. Quiero decir, puedes usar varios marcos. 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 forma incremental. Pero al final, no creo que sea recomendable por problemas de rendimiento. Quiero decir, podrías hacerlo. Y he escuchado a personas decir que les dimos a los desarrolladores la flexibilidad de usar el marco que querían usar. Y al final, terminaron usando solo un marco porque es con el que se sienten más cómodos. Entonces, sí. Sí, sí, sí. También tienes que pensar en el... Creo que tendrías que pensar en el costo del equipo, ya sabes. Cuesta mucho más tener un desarrollador que conozca todos estos marcos que tener uno que tal vez sea específico para uno solo.

Desafíos de la adopción de Microfrontends

Short description:

Adoptar un patrón de Microfrontends en un marco existente es un desafío porque requiere reestructurar la arquitectura para permitir implementaciones independientes. La característica clave de los Microfrontends es la capacidad de implementar partes de la aplicación de forma independiente sin reiniciar toda la aplicación. Esto se puede lograr con cualquier marco mediante la implementación de características como Webpack y Module Federation.

Eso es específico de uno. Sí. Ese es un punto. Tenemos algunas preguntas de nuestra audiencia, nuestra encantadora audiencia. La Dra. Jessie Pye preguntó, ¿NestJs se adapta a mis frontends actuales? NestJs. Bueno, probablemente necesitemos hablar con ellos sobre este tema. Nest, lo siento. Sí. Lo siento. Me perdí la pregunta. Bueno, la cosa es que adoptar un patrón de Microfrontend en un marco existente es un desafío porque es completamente una forma de construir la arquitectura. Y la característica clave de los Microfrontends que permite a cualquier marco utilizar este patrón es permitir entregas independientes para que puedas implementar partes de la aplicación de forma independiente sin tener que reiniciar toda la aplicación. Entonces, es posible con cualquier marco, la pregunta es, ya sabes, hay que reestructurarlo para permitir implementaciones independientes. Y características como Webpack, Module Federation.

Comunicación entre módulos en Micro Frontends

Short description:

Los módulos en micro frontends deben mantenerse lo más independientes posible, evitando el acoplamiento fuerte. Si bien es crucial mantenerlos independientes y cargar los datos que necesitan, hay casos en los que la comunicación es necesaria. Puedes elegir mecanismos como enviar eventos o utilizar herramientas de gestión de estado como Redux. Sin embargo, es importante evitar el acoplamiento fuerte entre los micro frontends.

podría ayudar con eso. Entendido. Eso en realidad se relaciona con nuestra próxima pregunta de Maxim Leont. ¿Cómo resuelves los problemas de comunicación entre módulos? Y Danji también preguntó cómo se comunican los módulos entre sí. Bueno, en cuanto a la comunicación, puedes elegir qué mecanismos de comunicación quieres utilizar, pero lo principal que debes tener en cuenta es que los módulos deben mantenerse lo más independientes posible. No es como en el desarrollo tradicional de aplicaciones donde simplemente pasas los datos en cascada o utilizando props. Con micro frontends es muy importante mantenerlos independientes 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 en los que eso no es posible y necesitas enviar comunicación y actualizar otros micro frontends según el estado de otros micro frontends. En ese punto, puedes elegir tu mecanismo. Puedes usar simplemente enviar eventos, esa es una solución. Otras personas prefieren utilizar una gestión de estado como una 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 nuevamente,

Migración e Infraestructura de Micro Frontends

Short description:

David Liam pregunta sobre cómo migrar un equipo de microservicios con una interfaz de usuario para cada servicio a micro frontends. El mejor lugar para comenzar es cuando tu empresa ya utiliza microservicios, tiene aplicaciones a gran escala y utiliza Kubernetes. La implementación de micro frontends permite la división de dominios y la propiedad de partes específicas por parte de los equipos. La tendencia de los backends para frontends simplifica el proceso, ya que el microservicio backend proporciona información a un solo frontend. La infraestructura es gestionada por otros equipos, pero los nuevos micro frontends tienen su propio repositorio y configuración automatizada de infraestructura. Esto elimina la necesidad de comenzar desde cero y garantiza una gestión y implementación sencillas en diferentes entornos. Los micro frontends se pueden implementar sin renderizado en el lado del servidor si no es necesario para la aplicación.

Es muy importante, no acoplarlos. Sí, eso suena como si fuera a ser un lío si están demasiado acoplados. David Liam pregunta si tienes alguna recomendación sobre cómo un equipo de microservicios con una interfaz de usuario para cada servicio podría migrar a micro frontends. En realidad, ese es el mejor lugar para considerar una arquitectura de micro frontends. Entonces, si tu empresa ya utiliza microservicios, tiene aplicaciones a gran escala y utiliza Kubernetes, y tienes muchos equipos distribuidos que son dueños de 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 simplemente puedes darle al equipo la responsabilidad de esa parte. Y ellos serán responsables del backend y del frontend. Además, hay una nueva tendencia, que son los backends para frontends, donde el microservicio backend se encargará de proporcionar la información solo a un frontend. Y si sigues el patrón de micro frontends, eso será más fácil, porque significa que el equipo puede ser dueño de 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 ser dueño del frontend y del backend. Andre está interesado en la infraestructura. Así que pregunta, ¿cómo se ve la composición de los equipos en Amex? Has dicho que cada módulo tiene su propio pipeline de CI/CD. ¿También son responsables de mantener estas infraestructuras? ¿Cómo se ve cuando se forma un nuevo equipo? ¿Cómo empiezan con su propio módulo? Correcto. La infraestructura es algo que es gestionado por otros equipos, pero tenemos todo configurado por defecto. Entonces, cuando comienzas un nuevo micro frontend, obtendrás tu propio repositorio y hay cierta automatización para crear la infraestructura para ello. Así que podrías crear alguna automatización para agregar todos los trabajos que se requieren para la implementación de esos micro frontends. Es parte de la incorporación a la infraestructura y con una automatización agradable, es algo 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 simplemente funcionará sin problemas. Eso es increíble y probablemente ayuda con la velocidad del equipo para que haya menos costos generales cuando comienzas, ¿verdad? Sí, es correcto. Entonces no necesitas preocuparte por la infraestructura, solo necesitas crear tu micro frontend, implementarlo y luego todo se implementará en los diferentes entornos. Eso es muy bueno. Quiero eso. Sí, tenemos otra pregunta. En realidad, tenemos toneladas de preguntas. A la gente le encanta esta charla, felicitaciones. House of Alejandro pregunta, dice, presentación impresionante. Estoy de acuerdo. Y también preguntan, ¿qué opinas sobre los micro frontends sin renderizado en el lado del servidor? ¿Sería tan buena solución como un enfoque de renderizado en el lado del servidor? Bueno, el renderizado en el lado del servidor es algo que hemos agregado a nuestros micro frontends, pero no significa que tengas que hacerlo. Y encontrarás la respuesta a esa pregunta en si realmente necesitas el renderizado en el lado del servidor en tu aplicación. Entonces, si tienes una aplicación renderizada en el lado del cliente que cumple con los requisitos y no tienes que preocuparte por el SEO o algo así, nuevamente, las reglas que se aplican cuando eliges el renderizado en el lado del servidor o el renderizado en el lado del cliente se aplican en el mismo caso. La única diferencia es que esas aplicaciones

Server-side Rendering and Bundle Size

Short description:

En nuestro marco de trabajo, tenemos renderizado en el lado del servidor, pero las aplicaciones solo del lado del cliente con micro frontends también son más fáciles. Si es una aplicación de una sola página, solo del lado del cliente, eso también funcionaría. Limitamos el tamaño del paquete de micro frontend a 250K, logrado a través de webpack externals y dynamic import. ¡Gracias a todos por las excelentes preguntas!

Los micro frontends se implementan de forma independiente. Por lo tanto, es bueno que en nuestro marco de trabajo tengamos renderizado en el lado del servidor, pero también serán más fáciles las aplicaciones solo del lado del cliente con micro frontends. Eso es algo a tener en cuenta. El renderizado en el lado del servidor también agrega cierta complejidad. Entonces, 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í. William preguntó y tenemos esta última pregunta muy breve. Así que no hay 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 solucionaste? Esta es una gran pregunta. Tenemos un límite de 250K para el tamaño del micro frontend como referencia. Y la forma en que logras eso, para que el tamaño del paquete no sea excesivo, es mediante el uso de una combinación de webpack externals y dynamic import. De esta manera, puedes lograr un tamaño de paquete más pequeño. Pero esa es la principal preocupación, asegurarnos de que no sean demasiado grandes. Esa es una buena regla. Qué gran pregunta. Muchas gracias a todos los que hicieron preguntas. Ruben, quedan un par de preguntas si quieres ir a Discord y responderlas. Y demos un gran aplauso virtual a Ruben. Ruben, muchas gracias por unirte a nosotros y gracias por esa increíble charla.

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.
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
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.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
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 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.