Rendimiento de Micro-Frontends y Caché de Datos Centralizada

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

¿Qué hago en American Express? Bueno, formo parte de un equipo que mantiene un marco de micro front-end llamado OneApp. Es como un meta marco que utilizamos en American Express. Y este marco es de código abierto, y es utilizado por aproximadamente 2,000 desarrolladores, por lo que hay un equipo de 2,000 desarrolladores en Amex que utilizan 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, ¿qué es lo primero que se te viene a la mente? Bueno, el rendimiento. Necesitamos asegurarnos de que todos esos millones de usuarios tengan un buen rendimiento. Ahora, antes de comenzar con la sección de rendimiento, voy a sacar esto de en medio porque nos preguntan esto bastante. He visto este tweet muchas veces. ¿Las carpas de micrófono ya son una cosa? O la otra pregunta es, ¿por qué no podemos simplemente usar componentes? Permítanme responder esa pregunta brevemente antes de entrar en la sección de rendimiento. Bueno, las carpas de micrófono, sí, son una cosa. Y, además, han estado presentes desde hace un tiempo. No es como si fueran algo nuevo o una tecnología completamente nueva. Han estado presentes durante 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 aviso aquí. No voy a tratar de convencerte de que las carpas de micrófono son geniales y que deberías empezar a usarlas mañana. Ese no es el motivo por el que estoy aquí hoy. Pero si usas carpas de micrófono, obtendrás beneficios realmente buenos. Como el principal, en mi opinión, que son las implementaciones independientes. Entonces, si tienes un equipo grande o varios equipos, pueden implementar de forma independiente. Pueden tener sus propios repositorios y simplemente hacer su propia cosa, todo se configura y pueden implementar de forma independiente. Diferentes partes del sitio web, de la aplicación web. Lo bueno de OneApp es que no tenemos que reiniciar el servidor. Puedes implementar una nueva versión y se carga automáticamente sin reiniciar el servidor. Si no te he convencido con esto, traje algo de pizza, si alguien quiere 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 existen muchos conceptos erróneos y mitos alrededor de las carpas de micrófono.

El mayor mito, con diferencia, es que son malas para el rendimiento. Sí, ese es el mayor mito sobre las carpas de micrófono, y permítanme decirles... hay una razón para esto, y he descubierto por qué la gente piensa que las carpas de micrófono son malas para el rendimiento. Y la razón es que la gente piensa que las carpas de micrófono consisten en mezclar bibliotecas en la misma página, por lo que tenemos React, Angular, Vue, Svelte e Infinity Dash en la misma página. ¿Es eso de lo que se tratan las carpas de micrófono? Bueno, permítanme decirles 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. Permítanme preguntarles, ¿es eso una buena idea? ¿Es eso una buena idea? Mi amigo Ken cree que sí es una buena idea. No es una buena idea. Sí, pueden usar React, Angular y todos estos frameworks en la misma página, pero solo porque pueden, no significa que deban hacerlo. Aunque hay un caso, un caso de uso específico donde podría ser una buena idea. No es genial, pero es un caso válido de 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 han tenido que reescribir su antigua aplicación AngularJS en React? ¡Yo! Es muy común. Estos son casos de uso muy comunes. Durante los últimos cinco, seis, siete años, AngularJS no es bueno, así que lo reemplazamos con React. ¿Qué hacemos? Simplemente detenemos por completo el desarrollo, decimos a los gerentes de producto: lo siento, no podemos agregar más funciones 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 transformar tu aplicación de forma incremental. No tienes que hacer una transformación completa de golpe, reescribir 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 partes de la interfaz de usuario.

Lo mejor es, ¿podemos comenzar ruta por ruta? Sí, puedes hacerlo, pero cuando tienes múltiples partes 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 utilizar React, el resto va a utilizar Angular, y luego en algún momento, esto es clave, eliminas Angular. No mantienes ambos en la misma página ¡por el rendimiento! Sí, no deberíamos hacer eso. 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, como una estrella, letra pequeña. Depende de tu implementación. Todo en la arquitectura depende de cómo lo implementes.

Entonces, si tienes una implementación incorrecta de las carpas de micrófono, serán realmente malas para ti. Si tienes una buena implementación, serán 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. Lo primero es que esto es un regalo. Esto es gratis. Más o menos. Las carpas de micrófono pueden ayudarte a reducir el tamaño de tus paquetes y, sí, todavía nos preocupamos por el tamaño de los paquetes. No deberíamos enviar tanto JavaScript a nuestros usuarios si no lo necesitan. Así que lo primero es porque las carpas de micrófono son unidades independientes, son su propia cosa Luego tendrán sus propios paquetes de JavaScript, y obtienes fragmentación de código de forma automática, así que no tienes que preocuparte por la fragmentación de código y dónde fragmentarlo porque cada carpa de micrófono tendrá su propio paquete. Esos tamaños de paquete, por ejemplo, intentamos mantenerlos pequeños. Nos esforzamos mucho en mantenerlos pequeños por razones de rendimiento. Así que esto es un regalo.

Una cosa que debes evitar, y eso es lo siguiente, son las dependencias duplicadas. 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 externals, y asegurarnos de que podemos acceder al mismo código y tener nuestros tamaños de paquete, nuevamente, pequeños. Debemos evitar las dependencias duplicadas, porque todas están usando lo mismo. ¿Por qué tener nuestras propias copias? Esto es especialmente malo, nuevamente, volviendo al tamaño del paquete para las personas que tienen conexiones a internet lentas dispositivos móviles, todos sabemos esto. Debemos evitar las 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 es realmente inteligente cosas. No deberíamos tener React, múltiples copias de React en la misma página. Si los micro front-ends son independientes, ¿cómo lo hacemos? Hay muchas formas de hacerlo. Pero esto es increíble. Hay algo nuevo llamado modificación, y tiene una API divertida llamada API compartida. Cuando vi esto, pensé, wow, he estado esperando esto durante mucho tiempo, porque quiero que mis micro front-ends tengan su propia copia de la dependencia si se están renderizando de forma aislada. Si se están renderizando de forma aislada, necesitas tu propia copia porque no tienes ningún contenedor, no tienes ninguna aplicación que proporcione 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 necesita React y mi biblioteca compartida o lo que sea.

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

Ahora, en la segunda parte de mi charla, hablaré sobre la obtención de datos distribuida y el concepto de microphone tends. Y déjame detenerme aquí. Sé lo que estás pensando. Estás mirando esto y preguntándote, ¿qué es esto? ¿Qué? Ahora, estamos acostumbrados a hacer esto. Básicamente, cargo mis datos en mi página. Estoy usando Next.js o cualquier otro metaframework que tengas, como obtener tus props del lado del servidor o cualquier otra cosa, 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 los microphone tends... Oh, ¿qué es esto? Esto es diferente. Cada microphone tend carga sus propios datos. Y, recuerda, estos se pueden implementar de forma independiente. Son como mini aplicaciones. Antes de que me critiques y digas, ¿por qué esto? Esto no está bien. Permíteme explicar por qué. ¿Por qué? ¿Por qué cada microphone tend carga sus propios datos? Porque necesitan ser independientes. Necesitan todos los datos para renderizar y necesitan evitar pasar datos de otros microphone tends porque eso causaría un acoplamiento indeseado. Regla número uno, si no quieres tener problemas, no acoples tus microphone tends. Tengo una publicación de blog muy buena que habla sobre las mejores prácticas, y esa es la más importante. Si comienzas a acoplar tus microphone tends, dejas de obtener todos los beneficios y terminas con el odiado monolito distribuido, que es un desastre, nadie sabe qué hace y si cambias algo, se rompe en todas partes. Eso es completamente lo opuesto a lo que se trata de los microphone tends. Entonces, 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 necesita. No necesitan preocuparse por el contexto, de dónde vienen los datos o si necesitan poner el contenedor y el contenedor tiene que proporcionarlo porque cargan sus propios datos.

Ahora, ¿qué hay de malo en esto? Si cada microphone tend carga sus propios datos, ¿qué va a suceder? ¿Alguien? Estamos haciendo tantas solicitudes a la API, ¡mira! El microphone tend del usuario se renderiza en el encabezado, los datos del usuario. El dashboard de microphone tends carga al usuario, vuelven a cargar los datos, por lo que tenemos tres solicitudes a la red. ¿Esto es malo para el rendimiento? ¡Por supuesto que sí! ¡Esto es como, no! ¿Por qué estás haciendo esto? Entonces, en Amex encontramos una solución, okay, hagamos una caché compartida distribuida. ¿En qué se diferencia esto de una caché normal? Es así, como expliqué con anterioridad, si estás renderizando tu microphone tend de forma aislada, toma su propia caché, pero tenemos un lugar donde si alguno de los microphone tends también ha solicitado los mismos datos, no haré esa solicitud a la API, te daré la caché. Cosas de caché bastante estándar. Así que creamos esta biblioteca de obtención de datos muy, muy básica.

Es muy, muy, no es básico, es simple. Básicamente, es un envoltorio alrededor de fetch, y tiene hooks de React y eso es todo. Bueno, en realidad no es todo. Tiene la capa de caché. Fue la solución más sencilla que pudimos encontrar porque podríamos haber sobreingenierizado y tratado de encontrar 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 eso? Sí, puedes. Pero, Adamic, sentimos que necesitábamos algo muy simple, así que envolvamos fetch alrededor de los hooks y pongamos una caché compartida encima. Sí, solucionó nuestro problema de múltiples llamadas a la API en la misma página.

Ahora, esta es la parte que siempre digo, gente, antes de llegar a la conclusión, tengo una demostración, pero no estaba funcionando hace 20 minutos. Así que, si se rompe, siempre digo a la gente, deberían grabar sus demostraciones, la codificación en vivo no es buena, ¡y aquí estoy haciendo codificación en vivo! De acuerdo.

Entonces, ¿todos pueden verlo? Sí, eso es perfecto. Tenemos una configuración muy básica de carpa de micrófono aquí. Tenemos nuestra carpa de micrófono de usuario, que generalmente se renderiza en el encabezado, o tienes una carpa de micrófono de encabezado. Por cierto, el caso de uso más común para las carpas de micrófono, el más común que he escuchado, es el encabezado y el pie de página. No lo necesitas para nada más. Ese probablemente sea tu caso. Hay casos más avanzados para empresas a gran escala. Si tu empresa tiene un equipo que se encarga del encabezado, y el encabezado es tan complicado, y el pie de página es tan complicado, tienen tantas cosas diferentes, y quieres asegurarte de que todos tus otros equipos tengan la misma versión del encabezado y el pie de página, las carpas de micrófono serían una buena idea si quieres implementarlo y mantenerlo simple. No tiene que ser complicado. Este es otro mito sobre las carpas de micrófono. No tienen que ser complicadas. Incluso puedes comenzar con iframes. No estoy diciendo que uses iframes, pero puede ser simplemente iframes. Así que tenemos esta configuración muy básica aquí con el encabezado con algunos usuarios, y tengo algunas películas, y puedes ver que la carpa de micrófono de usuario se renderiza dentro de las películas nuevamente porque ¿por qué no? Quiero usarla nuevamente allí, y no puedo pasar los datos desde aquí hasta allá porque estoy acoplando completamente mi carpa de micrófono de usuario con mi carpa de micrófono de películas. Todos sabemos que eso es malo. No deberíamos hacer eso. Veamos qué sucede. Si hago esta solicitud y no funciona. Oh, querido. Espera. Reiniciemos el servidor. Eso es lo que me preocupaba. Sí, creo que es el Wi-Fi. Ahí vamos. Déjame hacer eso de nuevo. Borra la red. ¿Qué es eso? Eso no es bueno.

Tenemos una, dos, tres, cuatro, cinco solicitudes de API diferentes. Sí. No quiero eso, porque todas mis carpas de micrófono solo están cargando los mismos data y están haciendo diferentes solicitudes en el cliente.

Vamos a 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, por lo que es como si tuvieras diferentes carpas de micrófono que tienen su propio contexto y simplemente nos aseguramos de que haya un único contexto verdadero que mantenga todas las cachés sincronizadas.

Entonces, ¿qué sucede cuando hago eso? Borremos la pestaña de red de las solicitudes. Eso es mucho mejor. De acuerdo. Solo tenemos dos solicitudes de API. Vamos a obtener el usuario, vamos a obtener las películas. Ya tengo los datos del usuario, así que solo dame la caché. Eso está bien. Ahora esto es algo básico. La fortaleza principal de nuestro marco 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 lograr el renderizado del lado del servidor con microfrontends es absolutamente difícil, y hay tantos, el creador de modules está tratando de hacerlo funcionar con next modules. Es realmente difícil. Creo que logró hacerlo. Así que habilitemos el renderizado del lado del servidor. Nuevamente, no voy a explicar esto. Esto es solo nuestra versión de obtener props del lado del servidor, o obtener tus data desde el servidor. Estoy haciendo la misma llamada de API en el servidor y en el cliente. Veamos qué sucede. ¡Oh, no sucedió nada! Espera. No esperamos que suceda nada, porque no hay una solicitud en el cliente.

Si no me crees, hagamos la prueba adecuada. Así es como hackeas HTML. Hay. Renderizado del lado del servidor. Aquí está Luke Skywalker. Está funcionando. Y el truco es que nuestro marco de micro front-end mantiene la caché entre el servidor y el cliente sincronizada, por lo que cuando el servidor está descargando los data, entonces el cliente está como, oh, los data ya están en el servidor. Ya tengo mi caché. No necesito hacer una solicitud de búsqueda. Solo obtengamos los data de la caché.

Lo mejor de esto es que puedes alternar entre la obtención de data del front-end y del back-end. Es 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 este rollo de los micro front-end es tan complicado y no quiero hacerlo? También hay un problema muy particular. Entonces, si no tienes ese problema, ¿por qué intentas solucionarlo? Bien. Si tienes este problema, bueno, los micro front-end pueden ayudarte a mejorar la experiencia del desarrollador.

Ahora, hay un argumento en contra. Espera. ¿Entonces estás diciendo que esto solo se trata de la experiencia del desarrollador? Sí. En cierto modo. Problemas organizativos y problemas de escalabilidad. Pero al mismo tiempo, si solucionas tu experiencia del desarrollador, si solucionas tus problemas organizativos para que tus equipos puedan implementar de forma independiente, serán más eficientes. Lo que significa que si tienes que corregir 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 carpa de micrófono, y está aislado, y está desacoplado, lo que significa que puedes implementarlo, corregir el error, nadie más sabía que era un error. Todos los equipos siguen haciendo lo suyo. Así que ayuda tanto a los problemas organizativos como a la experiencia del desarrollador. Pero como vimos, no tienen que ser malos para la experiencia del usuario.

También pueden ser realmente buenos para la experiencia del usuario si los hacemos funcionar para nosotros y solucionamos todos estos problemas de rendimiento.

Este soy yo. Muchas gracias. Sí. Genial. Muchas gracias.

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

Voy a empezar 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? Vale. Así que puedes solucionar ese problema. Básicamente lo que debes hacer es tener un equipo que pueda implementar esa biblioteca compartida. Puedes tener múltiples versiones con micro front-ends. Esto es algo realmente... Esto es algo que es... La gente se pregunta, ¿qué? Los micro front-ends tienen la misma numeración de versiones. Así que tienes 1.2.2. Y mi orquestación dice que quiero 1.2.3 y aún no estoy listo para actualizar, entonces está bien. Eran como dependencias. Pero no son dependencias porque puedes implementarlos en diferentes momentos. Así que no tienes que venir y descargar npm 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 profundizar más... Esa es una excelente 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 trabajan en ellos? Es algo organizacional. Esta es una pregunta organizacional. Y es una buena pregunta. Porque, nuevamente, los micro front-ends son como una respuesta a los problemas organizacionales. Una respuesta técnica, pero la respuesta organizacional depende de tu empresa. Recomendamos... Recomiendo que tu empresa tenga lo que llamamos el equipo de DevOps... Asegúrate de que se encarguen de sus bibliotecas de componentes, asegúrate de que todos sigan el mismo estilo y puedes crear plantillas. Para cada micro front-end, tienes un generador o plantilla. Alguien toma las decisiones y asegúrate de seguir las mismas prácticas de codificación que haces con cualquier otra cosa. La única diferencia es que estos... No tienes que hablar con ellos. Pueden hacer lo suyo y pueden implementarse de forma independiente, no tienen que hablar con nadie para implementar una nueva versión.

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

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

Muchas gracias. Realmente disfruté esa charla. Soy un gran fanático de la codificación en vivo. Así que estoy feliz de que también lo hayas hecho. Denle un aplauso. Pero una cosa más antes de que abandones el escenario. Tienes que elegir tu pregunta favorita para que esa persona pueda acercarse al frente o tal vez encontrarnos en línea y obtener una camiseta. ¿Cuál fue tu pregunta favorita? Ok, creo que la pregunta sobre la versión es interesante porque la gente no la hace muy a menudo. ¿Cuál? La pregunta sobre la versión. Así que si esa fue tu pregunta en el próximo descanso, acércate a nosotros en el frente si estás en línea. Nos pondremos en contacto contigo y muchas gracias. Gracias.