¿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.
This talk has been presented at Node Congress 2021, check out the latest edition of this JavaScript Conference.
FAQ
Un micro frontend es una forma de aplicar el patrón de arquitectura de microservicios al desarrollo frontend. Consiste en dividir la interfaz de usuario en características, componentes o secciones más pequeñas que pueden desarrollarse, probarse y desplegarse de manera independiente.
American Express ha sido pionera en la implementación de micro frontends desde 2016, utilizando un marco que permite la creación de micro frontends renderizados en el lado del servidor y su composición en la página, facilitando la gestión de la escalabilidad y la colaboración entre equipos.
Los micro frontends permiten entregas más rápidas y autónomas, reducen la complejidad en el código base, mejoran la escalabilidad, facilitan la actualización de tecnologías y mejoran la colaboración entre equipos al permitir que cada uno maneje diferentes partes de la interfaz de forma independiente.
Los micro frontends ayudan a resolver problemas de escalabilidad de grandes aplicaciones, dificultades en la gestión de múltiples equipos trabajando en un mismo código base, y desafíos relacionados con la implementación continua y la integración de nuevas características sin afectar el funcionamiento de otros componentes.
Los desafíos incluyen la gestión de la consistencia de la experiencia de usuario a través de diferentes micro frontends, la comunicación entre los componentes, la duplicación de funcionalidades entre equipos y la gestión de la seguridad y el rendimiento al tener múltiples elementos independientes.
La comunicación entre micro frontends debe mantenerse lo más independiente posible, pero para casos necesarios se pueden utilizar eventos, gestión de estado global como Redux, o cualquier otro mecanismo que permita la transmisión de información sin acoplar fuertemente los componentes.
Para el desarrollo local, cada micro frontend tiene su propio repositorio y canalización de CI. Los desarrolladores pueden trabajar de manera aislada y usar un entorno de desarrollo que emula la producción, asegurando que los módulos funcionen correctamente juntos antes de su despliegue.
No, los micro frontends son un patrón de diseño y no una solución única. Su aplicabilidad y efectividad dependen del caso de uso específico, tamaño de la aplicación, y la estructura del equipo. Es crucial evaluar si esta arquitectura es la mejor opción para las necesidades particulares de un proyecto.
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.
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.
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
Microfrontends are considered as a solution to the problems of exponential growth, code duplication, and unclear ownership in older applications. Transitioning from a monolith to microfrontends involves decoupling the system and exploring options like a modular monolith. Microfrontends enable independent deployments and runtime composition, but there is a discussion about the alternative of keeping an integrated application composed at runtime. Choosing a composition model and a router are crucial decisions in the technical plan. The Strangler pattern and the reverse Strangler pattern are used to gradually replace parts of the monolith with the new application.
There is a need for a standard library of APIs for JavaScript runtimes, as there are currently multiple ways to perform fundamental tasks like base64 encoding. JavaScript runtimes have historically lacked a standard library, causing friction and difficulty for developers. The idea of a small core has both benefits and drawbacks, with some runtimes abusing it to limit innovation. There is a misalignment between Node and web browsers in terms of functionality and API standards. The proposal is to involve browser developers in conversations about API standardization and to create a common standard library for JavaScript runtimes.
ESM Loaders enhance module loading in Node.js by resolving URLs and reading files from the disk. Module loaders can override modules and change how they are found. Enhancing the loading phase involves loading directly from HTTP and loading TypeScript code without building it. The loader in the module URL handles URL resolution and uses fetch to fetch the source code. Loaders can be chained together to load from different sources, transform source code, and resolve URLs differently. The future of module loading enhancements is promising and simple to use.
This talk covers various techniques for getting diagnostics information out of Node.js, including debugging with environment variables, handling warnings and deprecations, tracing uncaught exceptions and process exit, using the v8 inspector and dev tools, and generating diagnostic reports. The speaker also mentions areas for improvement in Node.js diagnostics and provides resources for learning and contributing. Additionally, the responsibilities of the Technical Steering Committee in the TS community are discussed.
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.
¿Alguna vez has trabajado en una aplicación monolítica de Next.js? Yo sí, y escalar una gran aplicación de React para que muchos equipos puedan trabajar simultáneamente no es fácil. Con micro frontends, puedes dividir un monolito frontend en piezas más pequeñas para que cada equipo pueda construir e implementar de forma independiente. En este masterclass aprenderás cómo construir aplicaciones de React grandes que escalen utilizando micro frontends.
Platformatic te permite desarrollar rápidamente APIs GraphQL y REST con un esfuerzo mínimo. La mejor parte es que también te permite aprovechar todo el potencial de Node.js y Fastify cuando lo necesites. Puedes personalizar completamente una aplicación de Platformatic escribiendo tus propias características y complementos adicionales. En el masterclass, cubriremos tanto nuestros módulos de código abierto como nuestra oferta en la nube:- Platformatic OSS (open-source software) — Herramientas y bibliotecas para construir rápidamente aplicaciones robustas con Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (actualmente en beta) — Nuestra plataforma de alojamiento que incluye características como aplicaciones de vista previa, métricas integradas e integración con tu flujo de Git (https://platformatic.dev/). En este masterclass aprenderás cómo desarrollar APIs con Fastify y desplegarlas en la nube de Platformatic.
Construyendo un Servidor Web Hiper Rápido con Deno
WorkshopFree
2 authors
Deno 1.9 introdujo una nueva API de servidor web que aprovecha Hyper, una implementación rápida y correcta de HTTP para Rust. El uso de esta API en lugar de la implementación std/http aumenta el rendimiento y proporciona soporte para HTTP2. En este masterclass, aprende cómo crear un servidor web utilizando Hyper en el fondo y mejorar el rendimiento de tus aplicaciones web.
La autenticación sin contraseña puede parecer compleja, pero es fácil de agregar a cualquier aplicación utilizando la herramienta adecuada. Mejoraremos una aplicación JS de pila completa (backend de Node.JS + frontend de React) para autenticar usuarios con OAuth (inicio de sesión social) y contraseñas de un solo uso (correo electrónico), incluyendo:- Autenticación de usuario - Administrar interacciones de usuario, devolver JWT de sesión / actualización- Gestión y validación de sesiones - Almacenar la sesión para solicitudes de cliente posteriores, validar / actualizar sesiones Al final del masterclass, también tocaremos otro enfoque para la autenticación de código utilizando Flujos Descope en el frontend (flujos de arrastrar y soltar), manteniendo solo la validación de sesión en el backend. Con esto, también mostraremos lo fácil que es habilitar la biometría y otros métodos de autenticación sin contraseña. Tabla de contenidos- Una breve introducción a los conceptos básicos de autenticación- Codificación- Por qué importa la autenticación sin contraseña Requisitos previos- IDE de tu elección- Node 18 o superior
Cómo construir una aplicación GraphQL fullstack (Postgres + NestJs + React) en el menor tiempo posible. Todos los comienzos son difíciles. Incluso más difícil que elegir la tecnología es desarrollar una arquitectura adecuada. Especialmente cuando se trata de GraphQL. En este masterclass, obtendrás una variedad de mejores prácticas que normalmente tendrías que trabajar en varios proyectos, todo en solo tres horas. Siempre has querido participar en un hackathon para poner algo en funcionamiento en el menor tiempo posible, entonces participa activamente en este masterclass y únete a los procesos de pensamiento del instructor.
Comments