Rendimiento de Micro-Frontends y Caché de Datos Centralizada

Hola a todos, y bienvenidos a mi presentación. Hoy es un tema muy interesante, y se trata del rendimiento. Mi nombre es Ruben. Soy ingeniero senior en American Express, y ese es mi usuario de Twitter si quieren seguirme.

¿Qué hago en American Express? Bueno, soy parte de un equipo que mantiene un marco de micro front-end llamado OneApp. Es como un meta marco que usamos en American Express. Y este marco es de código abierto, y lo utilizan alrededor de 2,000 desarrolladores, así que hay un equipo de 2,000 desarrolladores en Amex que usan este marco, y también nuestras aplicaciones son utilizadas por múltiples clientes en todo el mundo.

Ahora la pregunta es, cuando tienes tantos usuarios, ¿cuál es la primera cosa que te viene a la mente? Bueno, el rendimiento. Necesitamos asegurarnos de que todos esos millones de usuarios tengan un gran rendimiento. Ahora, antes de comenzar con la sección de rendimiento, solo voy a sacar esto de en medio porque recibimos esto bastante. He visto este tweet tantas veces. ¿Las carpas de micrófono son una cosa ya? O la otra es, ¿por qué no podemos simplemente usar componentes? Permítanme responder esa pregunta muy brevemente antes de entrar en la sección de rendimiento. Bueno, las carpas de micrófono, sí, son una cosa. Y, además, han existido por un tiempo. No es como si fueran algo nuevo o una tecnología completamente nueva. Han existido por un tiempo. Básicamente, lo que pueden hacer es ayudarte a escalar tus aplicaciones aplicando los mismos principios que tienes para los microservicios al front-end.

Ahora, un pequeño descargo de responsabilidad aquí. No voy a intentar convencerte de que las carpas de micrófono son geniales y que deberías venir y empezar a usarlas mañana. No estoy aquí por eso hoy. Pero si usas carpas de micrófono, obtendrás beneficios realmente agradables. Como, el principal, en mi opinión, son los despliegues independientes. Entonces, si tienes un equipo grande o múltiples equipos, pueden desplegar de manera independiente. Pueden tener sus propios repositorios y pueden simplemente tener lo suyo, todo configurado y pueden desplegar de manera independiente. Diferentes partes del sitio web, de la aplicación web. La cosa con OneApp es que no tenemos que reiniciar el servidor. Puedes desplegar una nueva versión y se carga automáticamente sin reiniciar el servidor. Si no te convencí con esto, traje algo de pizza, si alguien quiere algo de pizza. ¡No estoy tratando de convencerte aquí! Ahora, hay un problema con las carpas de micrófono, un gran, gran problema. Este problema es que hay muchos conceptos erróneos, y hay muchos mitos en torno a las carpas de micrófono.

El mayor de todos es que son malas para el rendimiento. Sí, ese es el mayor mito sobre las carpas de micrófono, y déjame solo... hay una razón para esto, y he encontrado por qué la gente piensa que las carpas de micrófono son malas para el rendimiento. Y la razón es, bueno, la gente piensa que las carpas de micrófono se tratan de mezclar bibliotecas en la misma página, así que tenemos React, y Angular, y Vue, y Svelte, y Infinity Dash en la misma página. ¿Es eso de lo que se tratan las carpas de micrófono? Bueno, déjame decirte que este es un mito falso, y por eso la gente piensa que las carpas de micrófono son malas para el rendimiento.

Lo primero que encuentran sobre las carpas de micrófono es que se trata de React, Angular, y todo en la página. Déjame preguntar, ¿es eso una buena idea? ¿Es eso una buena idea? Mi amigo Ken piensa que es una buena idea. No es una buena idea. Puedes, sí, puedes usar React, y Angular, y todos estos frameworks en la misma página, pero solo porque puedes, no significa que debas. Así que, aunque, este es solo un caso, un caso de uso específico donde podría ser una buena idea. No es genial, pero es un caso de uso válido tener múltiples frameworks en la misma página. Y este es el patrón Strangler.

El patrón Strangler es lo mejor que puedes hacer si estás migrando de una aplicación antigua, como una aplicación heredada a una nueva. ¿Cuántos de ustedes aquí han tenido que reescribir su antigua aplicación AngularJS en React? ¡Yo! Es muy común. Así que, estos son casos de uso muy comunes. Durante los últimos cinco, seis, siete años, AngularJS no es bueno, reemplazémoslo con React. ¿Qué hacemos? Simplemente detenemos completamente el desarrollo, decimos a los gerentes de producto, lo siento, no podemos hacer más características porque AngularJS es malo y no podemos mantenerlo. Necesitamos reemplazarlo con React. Lo primero que te dirán es, ¿qué? ¡No! ¡No puedes hacer eso! Quiero decir, probablemente algunas personas lo hacen. Lo que el patrón Strangler te ayudará a hacer es ayudarte a transformar tu aplicación de manera incremental. No tienes que hacer como una transformación de gran explosión, lanzamiento, reescritura de toda la aplicación. Lo que puedes hacer es comenzar a aplicar el patrón de micro front-end y el patrón Strangler para mejorar diferentes piezas de la UI.

Lo mejor es, bueno, ¿podemos comenzar ruta por ruta? Sí, puedes, pero cuando tienes múltiples piezas en la misma página que necesitas cambiar, y a veces una página es mucho trabajo, es como si toda la aplicación fuera una página. Con las carpas de micrófono, lo que puedes hacer es comenzar desde una parte muy pequeña en esa página que va a usar React, el resto va a usar Angular, y luego en algún momento, esta es la clave, eliminas Angular. No mantienes ambos en la misma página por el rendimiento. Sí, no deberíamos hacer eso. Así que este es el único caso donde podría ser útil tener múltiples frameworks en la misma página. Así que las carpas de micrófono pueden ser buenas para el rendimiento. Descargo de responsabilidad allí, como una estrella, letra pequeña. Depende de tu implementación. Todo en arquitectura, depende de cómo lo implementes.

Así que si tienes una implementación incorrecta de carpas de micrófono, van a ser realmente malas para ti. Si tienes una buena implementación, van a ser buenas para el rendimiento. Así que lo que voy a hacer a continuación es mostrarte primero cómo pueden ser buenas, también qué evitar y cómo resolver los problemas, los problemas de rendimiento que podrías encontrar si usas carpas de micrófono.

Genial. Así que lo primero es que esto es un buen regalo. Esto es gratis. Más o menos. Las carpas de micrófono pueden ayudarte a reducir los tamaños de tus paquetes y, sí, todavía nos preocupamos por los tamaños de los paquetes. No deberíamos enviar tanto JavaScript a nuestros usuarios si no lo necesitan. Así que el primero es porque las carpas de micrófono son unidades independientes, son su propia cosa Entonces tendrán sus propios paquetes de JavaScript, y obtienes división de código de inmediato, así que no tienes que preocuparte por la división de código y dónde dividir el código porque cada carpa de micrófono tendrá su propio paquete. Esos tamaños de paquete, por ejemplo, tratamos de mantenerlos pequeños. Tratamos muy, muy duro de mantenerlos pequeños por razones de rendimiento. Así que, este es un regalo.

Una cosa a evitar, y eso es lo siguiente, son las dependencias duplicadas. Así que, sí, tener múltiples dependencias. ¿Cuántos han tenido este problema donde todas mis aplicaciones tienen diferentes dependencias que necesitan ser compartidas, y hemos hecho cosas como externos, y asegurarnos de que podemos acceder al mismo código y tener nuestros tamaños de paquete, nuevamente, pequeños. Deberíamos evitar dependencias duplicadas, porque todos están usando lo mismo. ¿Por qué tienes nuestras propias copias? Esto es especialmente malo, nuevamente, volviendo al tamaño del paquete para personas que tienen conexiones de internet lentas, dispositivos móviles, así que todos sabemos esto. Deberíamos evitar dependencias duplicadas, y también React, no podemos tener React duplicado en la misma página. No podemos tener dos copias en la misma página. No sé por qué. En realidad, sí sé. Tiene algo que ver con el planificador que se borran entre sí, y todo eso realmente inteligente. No deberíamos tener React, múltiples copias de React en la misma página. Si los micro-front-ends son independientes, ¿cómo hacemos esto? Hay muchas maneras de hacer eso. Pero esto es increíble. Hay una nueva cosa llamada modificación, y tiene una API divertida llamada la API compartida. Cuando vi esto, pensé, wow, he estado esperando esto por tanto tiempo, porque quiero que mi micro-front-end obtenga su propia copia de la dependencia si se está renderizando de forma aislada. Si estás renderizando de forma aislada, necesitas tu propia copia porque no tienes ningún contenedor, no tienes ninguna aplicación proporcionando la dependencia, así que necesitas tu propia copia de React. Digamos que tenemos un segundo módulo, y ese segundo módulo o micro-front-end, también necesitan React y mi biblioteca compartida o lo que sea.

Lo que sucede es que, si estoy renderizando de forma aislada, bien, dame mi copia de React. Si hay otro micro-front-end y se están renderizando en el mismo contexto, lo que la API compartida va a hacer es esperar un momento, ya he cargado esta copia de React, déjame para cualquier otro micro-front-end o módulos que soliciten la misma dependencia. Así que, la federación de módulos especialmente es realmente buena, incluso solo para esta API. Si no quieres adoptar todo y no queremos complicar demasiado las cosas con micro-front-ends, esta es una característica realmente genial de la federación de módulos, si quieres echar un vistazo. Es una API compartida. Es como externals pero más allá. Y también hay algo sobre scopes donde puedes tener un scope A y un scope B y esa dependencia tendrá un scope para que no haya conflictos. Echa un vistazo a la documentación de la federación de módulos. Es brillante.

Ahora, la segunda parte de mi charla es la obtención de datos distribuida. Y déjame detenerme aquí. Sé lo que estás pensando. Estás mirando esto como, ¿qué es esto? ¿Qué? Ahora, estamos acostumbrados a hacer esto. Que es básicamente, cargo mis datos en mi página. Estoy usando Next.js o cualquier otro meta framework que tengas como tu get your server side props o lo que sea y luego eso hace todo el renderizado del lado del servidor y paso los datos a mis componentes. También podrías llamar a los datos en tus componentes. Pero este es más o menos el patrón.

Ahora con microphone tends... Oh, ¿qué es esto? Esto es diferente. Cada microphone tend está cargando sus propios datos. Y, recuerda, estos, puedes desplegarlos de manera independiente. Son como mini aplicaciones. Antes de que me dispares y digas, ¿por qué es esto? Esto no está bien. Déjame explicar por qué. ¿Por qué? ¿Por qué cada microphone tend está cargando sus propios datos? Porque necesitan ser independientes. Necesitan todos los datos para renderizar, y necesitan evitar pasar datos desde otros microphone tends porque eso causará un acoplamiento. Regla número uno, si no quieres tener un mal rato, no acoples tus microphone tends. Tengo un blog post muy bueno que habla sobre las mejores prácticas, y esa es la más grande. Si comienzas a acoplar tus microphone tends, dejas de tener todos los beneficios, y te encuentras con el odiado monolito distribuido que es un lío, nadie sabe lo que hace, y si cambias algo, se rompe en todas partes. Eso es completamente lo opuesto a lo que son los microphone tends. Así que, si los mantenemos independientes, lo que significa que cargan sus propios datos, podemos reutilizarlos en todas partes, y ese es uno de los beneficios de los microphone tends, son portátiles y reutilizables. Podemos tomar uno, ponerlo allí, carga todos los datos que necesitan.

No necesitan preocuparse por el contexto, o de dónde vienen los datos, o si necesito poner el contenedor y el contenedor tiene que proporcionarlo porque cargan sus propios datos. Ahora, ¿qué está mal con esto? Si cada microphone tend está cargando sus propios datos, ¿qué va a pasar? ¿Alguien? Estamos haciendo tantas solicitudes de API, ¡mira! El microphone tend de usuario se está renderizando en el encabezado, los datos del usuario. El dashboard de microphone tends carga el usuario, cargan los datos de nuevo, así que tenemos tres solicitudes de red. ¿Es esto malo para el rendimiento? ¡Por supuesto que lo es! Esto es como, ¡no! ¿Por qué estás haciendo esto? Así que, se nos ocurrió una solución en Amex que fue, está bien, hagamos una caché compartida distribuida. ¿Cómo es esto diferente de una caché normal? Es que, como expliqué con motion, por ejemplo, si estás renderizando tu microphone tend en aislamiento, toma su propia caché, pero tenemos un lugar donde si alguno de los microphone tends también ha solicitado los mismos datos, no voy a hacer esa solicitud de API, voy a darte la caché. Cosas bastante estándar de caché.

Es muy, muy, no es básica, es simple. Es básicamente un contenedor alrededor de fetch, y tiene React hooks, y eso es todo. Bueno, en realidad no lo es. Tiene la capa de caché. Fue la solución más sencilla que pudimos encontrar porque podríamos haber sobre-ingenierizado e intentado encontrar estas muchas soluciones diferentes. Esta no es la única solución, por cierto. Esto es lo que hicimos. Así que probablemente, puedo sentir que algunas de las preguntas serán, oh, ¿puedes usar eso o aquello? Sí, puedes. Pero, Adamic, sentimos que necesitábamos algo muy simple, así que ¿envolvemos fetch alrededor de los hooks y ponemos una caché compartida encima? Sí, solucionó nuestro problema con múltiples llamadas a la API en la misma página.

Ahora, esta es la parte que siempre digo, gente, antes de que lleguemos a la conclusión, tengo como una demostración, pero no estaba funcionando hace como 20 minutos. Así que, si se rompe, siempre le digo a la gente, deberías grabar tus demostraciones, el live coding no es bueno, ¡y aquí estoy haciendo live coding! Bien.

Entonces, ¿pueden ver todos? Sí, eso es perfecto. Así que, tenemos una configuración de microphone tent muy básica aquí. Tenemos nuestro user microphone tent, y usualmente se renderiza en el header, o tienes un header microphone tent. Por cierto, el caso de uso más común para los microphone tents, el más común que he escuchado es el header y el footer. No lo necesitas para nada más. Probablemente ese sea tu caso. Hay casos más avanzados para empresas a gran escala. Si tu empresa tiene un equipo que está haciendo el header, y el header es tan complicado, y el footer es tan complicado, tienen tantas cosas diferentes, y quieres asegurarte de que todos tus otros equipos tengan la misma versión del header y el footer, los microphone tents serían una buena idea si quieres implementarlo, y luego mantenerlo simple. No tiene que ser complicado. Este es otro mito sobre los microphone tents. No tienen que ser complicados. Incluso puedes comenzar con iframes. No estoy diciendo que vayas y uses iframes, pero puede ser solo iframes. Así que tenemos esta configuración muy básica aquí con el header con algún usuario, y tengo algunas películas, y puedes ver que el user microphone tent se está renderizando dentro del films nuevamente porque, ¿por qué no? Quiero usarla de nuevo allí, y no puedo pasar los datos de aquí para allá porque estoy acoplando completamente mi user microphone tent con mi films microphone tent. Todos sabemos que eso es malo.

No deberíamos hacer eso. Veamos qué sucede. Si hago esta solicitud, y no funciona. Oh, querido. Espera. Vamos a reiniciar el servidor. Esto es lo que me preocupaba. Sí, creo que es el Wi-Fi. Ahí vamos. Déjame hacer eso de nuevo. Limpiar la red. ¿Qué es eso? Eso no es bueno.

Tenemos una, dos, tres, cuatro, cinco solicitudes de API diferentes. Sí. No quiero eso, porque todos mis microphone tents están cargando los mismos datos y están haciendo diferentes solicitudes en el cliente.

Vamos al VS code. Lo primero que tenemos es un proveedor. No quiero entrar en detalles. Esto es solo una demostración. Es básicamente un contexto de React. Pero la diferencia con este contexto de React es que funciona en múltiples entornos, así que es como si tuvieras diferentes microphone tents que tienen su propio contexto y solo nos aseguramos de que haya un único contexto verdadero que mantenga toda la caché sincronizada.

Entonces, ¿qué pasa cuando hago eso? Vamos a limpiar la pestaña de red de fetch. Eso es mucho mejor. Bien. Solo tenemos dos solicitudes de API. Así que vamos a obtener el usuario, vamos a obtener las películas. Ya tengo los datos del usuario, así que solo dame la caché. Eso es bueno. Ahora esto es algo básico. La principal fortaleza de nuestro framework es el renderizado del lado del servidor.

Y una cosa que es realmente difícil en los microfrontends es el renderizado del lado del servidor. Eso es realmente, realmente difícil. Como conseguir que el renderizado del lado del servidor funcione con microfrontends es absolutamente difícil, y hay tantos, el creador de módulos está tratando de hacerlo funcionar con next modules. Es realmente difícil. Creo que lo logró. Así que vamos a habilitar el renderizado del lado del servidor. Así que de nuevo, no voy a explicar esto. Esto es solo como nuestra versión de get server side props, o obtener tus datos del servidor. Estoy haciendo la misma llamada de API en el servidor en un cliente. Veamos qué pasa. ¡Oh, no pasó nada! Espera. No estamos esperando que pase nada, porque no hay fetch en el cliente.

Si no me crees, hagamos la prueba adecuada. Así es como hackeas HTML. Ahí está. Renderizado del lado del servidor. Aquí está Luke Skywalker. Está funcionando. Y el truco es que nuestro framework de micro front-end mantiene la caché entre el servidor y el cliente sincronizada, así que cuando el servidor está descargando los datos, el cliente dice, oh, los datos ya están en el servidor. Ya tengo mi caché. No necesito hacer una solicitud de fetch. Simplemente obtengamos los datos de la caché.

Lo mejor de esto es que puedes cambiar entre la obtención de datos del front-end y del back-end. Así que es algo realmente, realmente genial. Esa fue mi demostración. Y solo una conclusión. No sé. Creo que estoy bien. Pero mi conclusión es, bueno, cuando alguien me pregunta, ¿por qué todo el asunto de los micro front-end es tan complicado y no quiero hacer eso? También hay un problema muy particular. Así que si no tienes ese problema, ¿por qué estás tratando de solucionarlo? Bien. Si tienes este problema, bueno, el micro front-end puede ayudarte a mejorar la experiencia del desarrollador.

Ahora, hay un contraargumento. Espera. Entonces, ¿estás diciendo que esto es solo sobre la experiencia del desarrollador? Sí. Más o menos. Problemas organizacionales y de escalabilidad. Pero al mismo tiempo, si mejoras tu experiencia del desarrollador, si solucionas tus problemas organizacionales para que tus equipos puedan desplegar de manera independiente, serán más eficientes. Lo que significa que si tienes que arreglar un error en producción, no tienes que preocuparte de que toda la aplicación se rompa porque solo necesitas asegurarte de que todas las pruebas pasen. Solo necesitas aplicar ese parche a tu microphone tent, y está aislado, y está desacoplado, lo que significa que puedes simplemente desplegar eso, arreglar el error, nadie más sabía que había un error. Todos los equipos continúan haciendo lo suyo. Así que ayuda a los problemas organizacionales así como a la experiencia del desarrollador.

Pueden ser realmente buenos para la experiencia del usuario si los hacemos funcionar para nosotros y hacemos que todos estos problemas de rendimiento desaparezcan.

Este soy yo. Muchas gracias. Sí. Increíble. Muchas gracias.

¿Te gustaría tomar asiento y vamos a repasar algunas preguntas? Voy a elegir las tres preguntas mejor valoradas en el slider. Eso significa que hay muchas preguntas. Sí, había tantas. Y no podremos llegar a todas ellas. Así que aquí está lo que. Si estás aquí, asegúrate de hablar con él después. Y si no, ve al chat espacial y podrás charlar más tarde en una de esas salas.

Voy a ir con la pregunta mejor valorada. Es de Adam Turner. Si actualizas algo como una biblioteca de componentes, tal vez después de un cambio de marca, ¿cómo puedes asegurarte de que todos los equipos actualicen la dependencia compartida al mismo tiempo? Bien. Así que puedes solucionar ese problema. Básicamente, lo que deberías hacer es simplemente tener un equipo que pueda desplegar esa biblioteca compartida. Puedes tener múltiples versiones con micro front-ends. Hay una realmente... Esto es algo que es... La gente está como, ¿qué? Los micro front-ends tienen el mismo versionado. Así que tienes 1.2.2. Y mi orquestación dice que quiero 1.2.3 y no estoy listo para actualizar aún, entonces está bien. Eran una especie de dependencias. Pero no son dependencias porque puedes desplegarlas en tiempo real. Así que no tienes que venir y descargar MPM install, micro front-end 1.2.3. Asegúrate de que pase. No, no tienes que hacer eso.

1.2.3 está listo para producción, ha sido probado. Ahora quiero cargarlo en mi página. Hecho. Eso es... Podemos ir más... Esa es una gran respuesta.

La siguiente pregunta es de Levi. ¿Cómo mantienes el estilo de codificación y las convenciones en múltiples micro front-ends y los equipos que están trabajando en ellos? Algo organizacional. Este es un tema organizacional. Y es uno bueno. Porque, de nuevo, los micro front-ends son como una respuesta a problemas organizacionales. respuesta técnica, pero la respuesta organizacional, depende de tu empresa. Recomendamos... Recomiendo que tu empresa tenga lo que llamamos el equipo DevOps... Solo asegúrate de que se encarguen de sus bibliotecas de componentes, asegúrate de que todos estén siguiendo el mismo estilo, y puedes simplemente crear plantillas. Cada micro front-end, tienes un generador o plantilla. Alguien está tomando las decisiones y solo asegúrate de que sigas las mismas prácticas de codificación que haces con cualquier otra cosa. La única diferencia es que estos son... No tienes que hablar con ellos. Pueden hacer lo suyo, y pueden desplegar de manera independiente, no tienen que hablar con nadie para desplegar una nueva versión.

Y por último, pero no menos importante, esta es de Jaefen. Mencionaste problemas de rendimiento con múltiples frameworks en la misma página. ¿Dirías que esto todavía se aplica con frameworks compilados como Svelte? Oh, no soy un experto en Svelte. No he... Lo he intentado. No estoy seguro. La razón principal por la que hay un problema con tener múltiples frameworks en las mismas páginas, obviamente estás cargando mucho más JavaScript. Así que si cargas Angular y view... Así que con Svelte, si no están cargando ningún JavaScript, bueno, necesitamos mirar... No estoy seguro de cómo van a chocar.

No es que no puedas hacerlo. Quiero decir, puedes. Podrías hacer algunas optimizaciones para sortearlo, y como mencioné, hay un caso de uso para ello. Así que cuando tienes Angular como una aplicación antigua, bueno, necesitas optimizar para eso. No hay forma de evitarlo porque estás actualizando. Así que sí, podrías optimizarlo y si Svelte no tiene nada del lado del cliente que vaya a hacer que tu aplicación sea enorme, entonces potencialmente, sí.

Muchas gracias. Realmente disfruté esa charla. Soy un gran fan del live coding. Así que feliz de que lo hicieras también. Denle un aplauso. Pero una cosa más antes de que dejes el escenario. Tienes que elegir tu pregunta favorita para que esa persona pueda venir al frente o tal vez encontrarnos en línea y obtener una camiseta. ¿Cuál fue tu pregunta favorita? Bien, creo que la de versionado es interesante porque la gente no pregunta eso muy a menudo. ¿Cuál? La de versionado. Así que si esa fue tu pregunta en el próximo descanso, ven a encontrarnos al frente si estás en línea. Nos pondremos en contacto contigo y muchas gracias.