Rendimiento de Micro-Frontends y Caché de Datos Centralizada

Rate this content
Bookmark

Los mitos comunes sobre los Micro-Frontends sostienen que son malos para el rendimiento o que los desarrolladores que implementan este estilo arquitectónico no se preocupan por las implicaciones de rendimiento porque se centran en solucionar los problemas de experiencia del desarrollador y organizacionales en lugar de centrarse en la experiencia del usuario, sin embargo, la realidad es completamente diferente. Los Micro-Frontends no son inherentemente malos para el rendimiento y, como suele ser el caso en el desarrollo de software, aprovechar al máximo la tecnología depende de una implementación correcta. Esta charla demostrará cómo los Micro-Frontends pueden hacer que tus aplicaciones sean más rápidas y resistentes mientras se mantienen los beneficios de las implementaciones independientes.

27 min
22 Oct, 2021

Video Summary and Transcription

La arquitectura de micro front-end, como las tiendas de micrófonos, puede ayudar a escalar aplicaciones aplicando los principios de microservicios al front-end. Las tiendas de micrófonos pueden ser beneficiosas para el rendimiento, dependiendo de la implementación. Pueden reducir el tamaño de los paquetes, evitar dependencias duplicadas y garantizar implementaciones independientes. La API compartida y la federación de módulos son características poderosas que permiten la gestión de dependencias. Los micro front-ends pueden mejorar la experiencia del desarrollador y la experiencia del usuario al abordar problemas organizativos y de escalabilidad.

Available in English

1. Introducción al rendimiento y a las carpas de micrófono

Short description:

¡Hola a todos! El tema de hoy es el rendimiento. Soy un ingeniero senior en American Express y trabajo en el marco de micro front-end llamado OneApp. Es de código abierto y es utilizado por 2,000 desarrolladores. Con millones de usuarios, el rendimiento es crucial. La arquitectura de micro front-end, como las carpas de micrófono, puede ayudar a escalar las aplicaciones aplicando los principios de microservicios al front-end. Las implementaciones independientes son un beneficio clave. Sin embargo, existen muchos conceptos erróneos y mitos alrededor de las carpas de micrófono.

¡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.

2. Carpas de Micrófono y Rendimiento

Short description:

El mayor mito sobre las carpas de micrófono es que son malas para el rendimiento. Esta idea errónea se basa en la creencia de que las carpas de micrófono implican mezclar múltiples frameworks en la misma página. Sin embargo, esto es un mito falso. Si bien es posible utilizar múltiples frameworks en la misma página, no siempre es una buena idea. El patrón Strangler es un enfoque recomendado para migrar de una aplicación antigua a una nueva, permitiendo una transformación incremental de la interfaz de usuario. Las carpas de micrófono pueden ser beneficiosas para el rendimiento, dependiendo de la implementación.

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.

3. Beneficios y Consideraciones de las Carpas de Micrófono

Short description:

Las carpas de micrófono pueden ayudar a reducir el tamaño de los paquetes al proporcionar unidades independientes con sus propios paquetes de JavaScript y fragmentación de código. Evite las dependencias duplicadas, incluyendo múltiples copias de React en la misma página. Utilice la nueva función de modificación y la API compartida para asegurarse de que los micro front-ends tengan sus propias copias de las dependencias al renderizar de forma aislada.

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.

4. API Compartida y Federación de Módulos

Short description:

Al renderizar micro front-ends de forma aislada, cada uno puede solicitar su propia copia de React. Sin embargo, si varios micro front-ends se renderizan en el mismo contexto, la API compartida se asegurará de que solo se cargue y comparta una única copia de React entre ellos. La federación de módulos, especialmente la API compartida, es una característica poderosa que permite implementaciones independientes y evita conflictos de dependencias. Consulta la documentación de la federación de módulos para obtener más información.

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.

5. Distributed Data Fetching and Microphone Tends

Short description:

Ahora, en la segunda parte de mi charla, hablaré sobre la obtención de datos distribuida y el concepto de microphone tends. Los microphone tends son mini aplicaciones que cargan sus propios datos, lo que permite la independencia y evita el acoplamiento. Esto garantiza la portabilidad y reutilización. Sin embargo, cargar datos individualmente para cada microphone tend puede generar múltiples solicitudes a la API y un rendimiento deficiente. Para solucionar esto, implementamos una caché compartida distribuida que elimina las llamadas redundantes a la API. Esta caché es una biblioteca básica de obtención de datos.

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.

6. Implementando una Solución Simple

Short description:

La solución que implementamos es un envoltorio simple alrededor de fetch con React hooks y una capa de caché. Fue la solución más sencilla para nuestras necesidades y resolvió el problema de múltiples llamadas a la API en la misma página.

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.

7. Demo de Configuración de Carpa de Micrófono

Short description:

Ahora, tengo una demostración para mostrarles. Tenemos una configuración básica de carpa de micrófono con una carpa de micrófono de usuario y una carpa de micrófono de encabezado. Las carpas de micrófono se utilizan comúnmente para el encabezado y el pie de página. No tienen que ser complicadas e incluso pueden comenzar con iframes. En nuestra configuración, la carpa de micrófono de usuario se renderiza dentro de la carpa de micrófono de películas, lo cual no es ideal. Veamos qué sucede cuando hacemos una solicitud. Tenemos cinco solicitudes de API diferentes.

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.

8. Solicitudes de API y Renderizado del Lado del Servidor

Short description:

Tenemos múltiples solicitudes de API para los mismos datos en diferentes carpas de micrófono. Para abordar esto, utilizamos un contexto de React que funciona en múltiples entornos, asegurando un único contexto verdadero para el almacenamiento en caché. Al borrar la pestaña de red de las solicitudes, reducimos las solicitudes de API a dos. La fortaleza principal de nuestro marco es el renderizado del lado del servidor, que es desafiante para los microfrontends. Habilitar el renderizado del lado del servidor implica realizar la misma llamada de API en el servidor y en el cliente.

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.

9. Beneficios de los Micro Front-Ends

Short description:

Si no me crees, hagamos la prueba adecuada. Nuestro marco de micro front-end mantiene la caché entre el servidor y el cliente sincronizada, lo que permite una recuperación eficiente de datos. Los micro front-end pueden ayudar a mejorar la experiencia del desarrollador al abordar problemas organizativos y de escalabilidad. La corrección de errores en producción se vuelve más fácil ya que la aplicación está desacoplada y aislada. Los micro front-end pueden beneficiar tanto a los problemas organizativos como a la experiencia del desarrollador sin comprometer la experiencia del usuario.

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.

QnA

Experiencia del Usuario y Actualizaciones de Dependencias Compartidas

Short description:

También pueden ser realmente buenos para la experiencia del usuario si los hacemos funcionar para nosotros y solucionamos todos estos problemas de rendimiento. ¿Te gustaría tomar asiento y repasar algunas preguntas? Voy a elegir las tres preguntas mejor valoradas en el deslizador. 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? Puedes solucionar ese problema teniendo un equipo que pueda implementar la biblioteca compartida y utilizando múltiples versiones con micro front-ends. Los micro front-ends tienen su propia numeración de versiones y pueden implementarse de forma independiente.

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.

Cargando y Manteniendo Micro Front-Ends

Short description:

1.2.3 está listo para producción. ¿Cómo mantienes el estilo de codificación y las convenciones en múltiples micro front-ends y equipos? Depende de tu empresa. Ten un equipo de DevOps para encargarse de las bibliotecas de componentes y asegurarse de seguir las prácticas de codificación. Cada micro front-end puede implementarse de forma independiente. Los problemas de rendimiento con múltiples frameworks en la misma página aún pueden aplicarse con frameworks compilados como Svelte.

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.

Optimizando Angular y Svelte

Short description:

Puedes optimizar una aplicación antigua de Angular al actualizarla. Si Svelte no agrega código del lado del cliente que aumente el tamaño de la aplicación, puede ser una solución potencial. Gracias por asistir a la charla y participar. La pregunta favorita del ponente fue sobre la versión, que no se hace comúnmente. Si fue tu pregunta, por favor acércate al frente o contáctanos en línea para tener la oportunidad de obtener una camiseta.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Workshop
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion