1. Introducción a la Revolución de los Micro Front-End
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
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
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
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
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.
Microfrontend Patterns
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
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
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
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
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.
Remix Conf Europe 2022
Node Congress 2022
React Advanced Conference 2022
JSNation 2023
JSNation Live 2021
React Summit 2022
