Cómo Hopin se está moviendo 10 veces más rápido: Microfrontends a escala

Hoy vamos a hablar de cómo Hoping se está moviendo diez veces más rápido con micro frontends a gran escala. Primero, permítanme presentarme. Mi nombre es Alex Lobera y me encanta React, TypeScript, por supuesto, micro frontends, salsa bachata y mi pareja, y no necesariamente en ese orden, por supuesto. Trabajo para Hoping como ingeniero principal y pueden encontrarme en Twitter como Alex Lobera.

Esta charla trata sobre la arquitectura de micro frontends y en cualquier arquitectura, todo es un compromiso, ¿verdad? Siempre estamos tomando decisiones sobre lo que es mejor para el trabajo. Estamos evaluando diferentes opciones. Estamos en una conferencia de React, por lo que React pesa más. Estamos evaluando cuál es la mejor opción. Para entender la arquitectura, es necesario comprender el contexto. Permítanme compartir con ustedes el contexto en nuestra aplicación o en nuestra organización. Hoping ha adquirido diferentes empresas. Tenemos un ejemplo. La forma en que nos organizamos es por áreas de productos. Luego tenemos equipos que trabajan en esos productos. Las empresas tienen pilas tecnológicas. En el caso de Hoping, usamos React. Jam utiliza Vue. Es posible que queramos combinar tecnologías en diferentes productos. Muy importante, los equipos trabajan en la misma interfaz de usuario. Tenemos equipos pequeños y puedes tener una sola página con diferentes características, y cada característica es propiedad de diferentes equipos. Todos juntos en la misma página. Queremos que esos equipos puedan trabajar muy rápidamente sin pisarse los unos a los otros. Entonces, ¿cuál es nuestra definición de micro frontends? Para nosotros, los micro frontends son una arquitectura y los consideramos como una aplicación de software donde dividimos las aplicaciones en una colección de aplicaciones más pequeñas y tienen una serie de características. Primero, están organizados en torno a capacidades empresariales. Son propiedad de un equipo pequeño. Son independientemente desplegables y, muy importante, están débilmente acoplados.

Aquí, por ejemplo, tenemos una interfaz de usuario y hay dos características. Voy a llamarlas aplicaciones porque, para nosotros, las características deben poder funcionar de forma independiente sin el contexto de la aplicación más grande. Aquí tenemos un chat y un perfil de usuario. Luego, cada equipo podrá implementarlos de forma independiente. Los construirán y los desplegarán en un CDN. Luego usamos webpack para obtener esas dependencias utilizando module federation e integrarlas en tiempo de ejecución.

Una vez que tenemos esos scripts, los montamos en árboles de componentes independientes. Así que aquí tenemos dos características, dos aplicaciones, por lo que tendremos dos árboles de componentes independientes con dos rutas. Es posible que queramos compartir algo de estado entre ellos. No alentamos a los ingenieros a compartir estado entre los micro frontends, pero hay algunos casos en los que podemos querer hacerlo. Para hacer esto, tenemos un almacén muy ligero que permitirá a los equipos compartir algo de estado, y es un almacén muy simple. No puede derivar un estado, por ejemplo, a diferencia de Redux o Recoil. Creemos que son demasiado potentes para este paradigma, por lo que tenemos una implementación más simple que colocará toda la lógica del estado dentro de los límites de cada aplicación. Nuestro objetivo, una vez más, es tener un sistema muy desacoplado.

Permítanme mostrarles una demostración. Ahora es cuando las cosas se ponen divertidas. En primer lugar, no estoy usando mi computadora portátil. Aquí está el primer experimento. Voy a cambiar a la otra computadora portátil. Así que aquí tenemos una aplicación React. La estamos renderizando aquí. Puedes ver el árbol de componentes. Puedo moverme por el árbol y ver que si estoy sobre el input, también se resalta en la interfaz de usuario, lo mismo para el botón, y también puedo ver la pestaña de red y estoy obteniendo algunas dependencias, puedo filtrar por React aquí, y puedes ver que descargo React y React DOM porque los necesitamos para montar esta aplicación, pero también puedo ver esto en el contexto de una aplicación NextJS. Y aquí, si miro el árbol de componentes, puedo ver este componente, esta es la aplicación NextJS, puedo desplazarme hacia abajo y cuando llego a este punto en el árbol, veo que estoy resaltando el perfil de usuario pero no veo el input y el botón que vi antes. Así que tenemos este montaje, puedo desplazarme hacia abajo y ver otro árbol, puedo ver mi input y mi botón aquí, por lo que hay dos árboles distintos. También puedo ver la pestaña de red y, si filtro React, veo que aquí no estoy descargando React o React porque, en el contexto de la aplicación, está compartiendo esas bibliotecas con la aplicación React. Echemos un vistazo a este Mount Micro Front-end que recibe una URL y un nombre. Voy a cambiar a la otra computadora portátil. Ok, WebStorm. ¿Cómo hago las cosas más grandes en WebStorm? No uso WebStorm.

¿Alguien sabe, como, si hago un comando más? ¿Qué dijiste? Oh, eso fue tan fácil. Gracias. Aprendiste algo. Yo sí. Así que volvamos. Voy a mirar este montaje aquí. Y quiero ver la función de montaje. Entonces lo que hago es recibir una URL, y esa URL, cargaré algunos scripts. Cuando esto esté listo, significa que la federación de módulos está lista para cargar algún script, algún módulo en este caso. Lo que voy a cargar es el perfil. Y lo tengo aquí. Este es el punto de entrada de esa aplicación. Observa que no estoy exportando componentes. Estoy exportando una función que tiene un argumento que es un elemento HTML, y lo que voy a hacer es montar mi aplicación en ese elemento, y también voy a devolver una función de desmontaje para limpiar esto.

Entonces puedo volver a la otra computadora portátil, y voy a buscar, voy a colapsar esto, y puedo ir al chat. Luego monto esta otra aplicación, esta aplicación de React. Puedo volver a la página de inicio y montar y desmontar. ¿Por qué hacemos todo esto, verdad? La razón por la que hacemos esto es porque queremos desacoplar nuestras aplicaciones, y si renderizamos todo en el mismo árbol de componentes, podríamos agregar potencialmente algún Redux u otra cosa en el contexto, y luego todas mis pequeñas aplicaciones usarían ese contexto implícito, ¿verdad? Y eso es malo, ¿verdad? Porque si mañana cambio la aplicación de nivel siguiente Redux u otra cosa, entonces también necesitaría cambiar mis otras aplicaciones. Aquí, por ejemplo, tenemos un proveedor, y si quiero usar este proveedor en el otro lado, también necesitaría agregar el proveedor en el contexto de la otra aplicación, y luego lo que necesitaría hacer es envolverlo explícitamente desde un lado y pasarlo al otro, ¿verdad? Cuando monto en esta ruta de creación, obtengo el contexto de un lado y lo paso al otro lado. Entonces, la razón por la que hacemos esto es porque queremos crear límites, y eso es muy útil. Eso es muy útil porque... Bueno, antes... Entonces una cosa que podemos hacer es, hablando del contexto, quiero mostrarte este proveedor en el que estábamos mirando, este proveedor ReactiveMap. Este es el almacén ligero que mencioné antes que usamos, y así puedo usarlo, por ejemplo, para agregar algún nombre, ¿verdad? Quiero cambiar el nombre en un lado de la aplicación, pero también quiero que otros lugares en mi aplicación reaccionen a ello. Entonces, si cambio el nombre a Alex, entonces esto reacciona, que es una aplicación diferente. Puedo mirar el perfilador y tal vez agregar algo aquí. Grabar. Guardar. Ver qué sucedió. Y solo mi chat fue la aplicación que reaccionó y se renderizó. Así que esto es realmente agradable. Ahora tenemos límites y podemos combinar y mezclar como dije antes. Digamos que tenemos un chat de Vue.js. El propósito de la demostración, no estoy diciendo que debamos hacer esto. Digamos que queremos reemplazar React con Vue. Podría ir a esta otra computadora portátil, y en la página donde estoy renderizando voy a cambiar por 87, ¿verdad? Tengo en este tablero estoy ejecutando la aplicación Vue.js, así que lo que voy a hacer es voy a cambiar esto. Y ahora si voy a la otra aplicación y recargo la página, no tengo la aplicación Vue.js lo cual es muy interesante. Lo siento, me confundí con esta computadora portátil. Entonces, si lo cambio en el lugar correcto y ahora voy a la otra computadora portátil, y ... Y recargo esta página, tengo la aplicación Vue.js. ¡Whoo! Nunca pensé que iba a recibir esta ronda de aplausos por mostrar Vue.js en una conferencia de React, pero nunca se sabe. Entonces, puedo mirar los elementos y seleccionar este div aquí donde tengo esta aplicación Next.js. Observa que se resalta toda la aplicación en el navegador.

Y puedo seleccionar esto, tengo este Vue.js dentro de la aplicación Next.js, y en realidad También puedo cambiar mi nombre, y también reacciona a ello. Similar, la misma experiencia, lo mismo que hice antes. ¿Por qué está sucediendo todo esto? Porque estamos creando límites entre nuestras aplicaciones, y porque tenemos contratos explícitos. Si cumplimos con esos contratos, todo debería funcionar.

De acuerdo. Así que volveré aquí. Eso es genial. Eso funciona más o menos, pero ¿qué pasa si sigo ese camino y luego tengo 100 aplicaciones, tal vez una, no sé, muchas aplicaciones, árboles de componentes React en mi aplicación. ¿Qué va a pasar? ¿Será eficiente? No lo sé. Tal vez algunos de ustedes se estén preguntando eso. Así que pensé en preparar una demostración para esto. Y tengo esta prueba de rendimiento que voy a... Entonces, aquí lo que tengo es una aplicación React que puede montar muchas aplicaciones. Si miro el árbol de componentes, tengo una aplicación que puede montar muchas otras aplicaciones. Puedes ver la creación de raíz aquí como tenemos en el otro lado. Puedo renderizar, digamos, diez aplicaciones. Así que estoy montando diez aplicaciones aquí. También puedo decir, de acuerdo. Voy a renderizar diez componentes cada uno. Ahora tengo diez aplicaciones con diez componentes. Podemos ver la memoria a la izquierda. Y a la derecha, tenemos un reloj. Estoy cambiando eso usando JavaScript así que si el hilo se vuelve muy ocupado porque estamos montando y calculando árboles, entonces se congelará. Así que hagamos un experimento. Si ejecutamos tal vez no tengamos mucho tiempo, así que vayamos directamente a 30,000 componentes. Veamos cuánto tiempo tarda en renderizarse en mi computadora portátil 30,000 componentes. Así que eso va a ser alrededor de seis segundos. Hagámoslo de nuevo solo por diversión, así puedo perder un poco más de tiempo en esto. 43 va a ser alrededor de 49. Seis segundos.

De acuerdo, genial. Es consistente. Entonces, ¿qué pasa si renderizo 3,000 aplicaciones? ¿Cuánto tiempo va a tomar? Fueron dos, tres segundos. Hagámoslo de nuevo. Los mismos dos, tres segundos. Hagamos la prueba final. Antes de renderizar, montamos 30,000 componentes. Ahora montemos 3,000 aplicaciones con diez componentes. Eso va a ser lo mismo. Vamos a referirnos. ¿Qué crees que va a pasar? Me quedan tres minutos. Vamos a ello. Diez. Y, oh, eso fue interesante. Espera. Cuatro, cinco. ¿Qué aprendimos aquí? Fue más rápido. Tengo algunos puntos de referencia que quiero compartir aquí. Lo hice con 100,000 componentes y algunas combinaciones de estos. Como puedes ver, en términos de memoria no cambió mucho. El tiempo para mostrar esos cambios fue diferente. React tomará más tiempo para renderizar muchos árboles de componentes. Sin embargo, no solo es React. También necesitas pintar esos cambios, y cuanto antes comiences a pintar, más rápido es. Puedes ver que a medida que aumentas los números, hay una diferencia significativa aquí. En resumen, esto no hará que tu aplicación sea más lenta. Estoy usando React 17. Espero que esto sea probablemente insignificante, tal vez con React 18, pero el punto aquí es que no haces esto, no divides tu aplicación en muchas aplicaciones porque es inteligente, es más rápido. Lo haces porque quieres crear límites, quieres desacoplar tu código y tus aplicaciones. Usa algunos principios, crea límites.

Puedes crear múltiples árboles de componentes. Es seguro. Usa contratos explícitos. ¡Ups! Usa contratos explícitos si deseas compartir un estado o contexto de un lugar a otro, hazlo explícito, obténlo de un lugar y pásalo a otro. Si decides compartir algún estado, te recomiendo mantener la lógica del estado dentro de los límites Para nosotros, utilizamos una tienda muy simple que no puede derivar un estado. Solo comunica cambios de etapa. Y creemos que Redux y Recoil, por ejemplo, esas herramientas, son demasiado poderosas para un paradigma como este. Aún puedes usar Redux pero úsalo dentro de tu aplicación, no para comunicarte entre tus aplicaciones.

¡Muchas gracias! Gracias. Gracias. Muy bien. ¡Entra en mi oficina, amigo! ¡Vamos a charlar! Déjame cerrar ambas laptops. DJ Alex! Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- ¡Wow! ¡Lo logré! No lo pensé. Respira.

Entonces, Alex! ¡Sí! ¿Micro frontends, eh? Sí, ese es el tema. Tenemos una pregunta del público. Puedes hacer preguntas en slide.do. El código es 2225. Y quieren saber, ¿cómo te aseguras de que los estilos no se mezclen entre aplicaciones, especialmente si las aplicaciones son antiguas y usan selectores globales? ¿Y las aplicaciones no están mutando paquetes compartidos? Bueno, quieres dar un espacio de nombres a tus estilos y asegurarte de que si usas componentes, evites el uso de estado global porque podría tener el mismo ámbito para diferentes paquetes si son completamente independientes. Así que diría que evites el estado global sin duda. Entonces, CSS global y estilos globales, y da un espacio de nombres a tus clases. Buen consejo. Buen consejo. ¿Cómo haces cumplir los contratos entre diferentes microaplicaciones? Al final, un contrato es una función con argumentos para nosotros, y lo que haces es que puedes tener dos tipos de comprobaciones, comprobaciones en tiempo de ejecución, que hacemos, como si intentas acceder a algo que no deberías, entonces obtendrás un error, y también usamos TypeScript, y la razón por la que usamos también comprobaciones en tiempo de ejecución es porque a veces los ingenieros les gusta usar TS ignore, así que es bueno tener un plan de respaldo. Yo nunca uso TS ignore. Yo tampoco, pero lo vi. Tú tampoco deberías. Billy preguntó, ¿es más rápido renderizar múltiples aplicaciones con componentes, en lugar de la otra forma, debido a cómo React reconcilia los cambios? ¿Árbol grande versus varios más pequeños? No sé la respuesta exacta, pero mi hipótesis es que comenzarás a pintar antes, en lugar de calcular más cosas, porque lo que es lento es pintar la interfaz de usuario, no JavaScript. JavaScript es mucho más barato, por así decirlo, que modificar el DOM. Así que cuanto antes comiences a hacer ese trabajo, más rápido será. Genial. Quiero preguntar, ¿recomendarías Microfrontend más view más Webstorm? ¿Es una gran combinación para introducir? Bueno, agregaría a eso que usar dos laptops tampoco es una buena idea, pero creo que hay cursos para cada caso. Necesitas encontrar un problema y luego usar la herramienta adecuada, y, no sé, tal vez en algún contexto tenga sentido hacer eso. Diría que todo depende del contexto y los requisitos, pero trata de no usar demasiadas laptops y demasiados frameworks al mismo tiempo. Probablemente sea una buena idea. Hay una pregunta aquí sobre Hoppin específicamente que quiero leer y también agregar un poco más. Steph O. pregunta, ¿cuántos ingenieros trabajan en Frontend en Hoppin y cómo se tomó la decisión de adoptar la arquitectura de Microfrontend, y también quiero agregar, ¿tiene algún tipo de efecto en el proceso o la organización en los equipos o desarrolladores en cuanto a si trabajan en una sola aplicación o en varias? Sí, es una buena pregunta.

Cuando me uní hace nueve meses, mi departamento, mi área de producto tenía 12 ingenieros en una aplicación Exodus. Ahora somos alrededor de 60 en la misma aplicación Exodus. Así que eso es demasiada gente en el mismo lugar. Encontramos una forma para que las personas trabajen de forma independiente y no se entorpezcan entre sí.

La forma en que operamos es más como tomar decisiones de abajo hacia arriba, entonces algunas personas dirán, `Ok, tenemos este problema, lo resolveremos`, y luego otros intentarán socializar esa idea y usarla. Así que es más una decisión de que tenemos este problema, luego comenzamos a construir nuestro propio marco de trabajo, como, y ahora otros departamentos también están usando estas herramientas, lo cual es genial. Influencers. Sí, diría eso. Este es uno muy popular. Tiene muchos pulgares arriba.

¿Qué gestión de estado recomiendas usar para comunicarse entre aplicaciones? Obviamente, el que estamos construyendo. La cosa es que no encontramos ninguna herramienta de gestión de estado que fuera lo suficientemente buena para las que son demasiado poderosas y que alientan a los desarrolladores a, ya sabes, cuando obtienes poder, lo usas. Así que queríamos crear algo muy simple, y por ejemplo, derivar un estado en eso no es una buena idea porque entonces tienes esta cosa centralizada que tiene lógica, y tuvimos que construir algo mucho más simple que las cosas que encontramos en la comunidad. Así que la respuesta es esperamos que algún día podamos hacerlo de código abierto y lo mostraré Pero diría que el que estamos creando. Deberías seguir a Alex en Twitter para obtener esas noticias, si llegan. Sí.

Desafortunadamente, no tenemos tiempo para más preguntas, pero Alex y Ruben van a tener una sala de discusión híbrida más tarde alrededor de las 2.10, justo aquí al lado del escenario, si quieres hacerles más preguntas o recibir consejos sobre micro-Frontend. Gracias, Alex. Eres libre de irte. ¡Brindemos por Alex, por favor!