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

Rate this content
Bookmark

Hopin es la startup de más rápido crecimiento en el mundo. Muchos ingenieros se unen cada mes. Empresas con diferentes tecnologías son adquiridas cada otro mes. Esto trae muchos desafíos a nuestra arquitectura front-end. En esta charla explicaré cómo estamos dividiendo nuestros monolitos de React y permitiendo la interoperabilidad utilizando múltiples árboles de React y variables reactivas.

25 min
22 Oct, 2021

Video Summary and Transcription

Esta charla discute cómo Hopin utiliza micro frontends para mejorar la velocidad de desarrollo y crear límites entre aplicaciones. Dividen las aplicaciones en aplicaciones más pequeñas y desplegables de forma independiente, propiedad de equipos pequeños. Utilizan webpack y federación de módulos para integrar dependencias en tiempo de ejecución y tienen una tienda ligera para compartir estado. La charla también aborda preocupaciones de rendimiento y la importancia de contratos explícitos y estilos de espacio de nombres para evitar conflictos entre micro frontends.

Available in English

1. Introducción a la Arquitectura de Micro Frontends

Short description:

Hoy vamos a hablar de cómo Hoping se está moviendo diez veces más rápido con micro frontends a gran escala. Para entender la arquitectura, es necesario comprender el contexto. 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.

Bueno, gracias a todos por unirse a mi charla y gracias a React Advance por tenerme aquí hoy. Vamos a hacer un pequeño experimento. Mi computadora portátil no funcionaba, así que tengo, como, voy a ser, como, me siento como un DJ con dos computadoras portátiles al mismo tiempo, y tengo una conectada a la otra, veamos cómo va.

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.

2. Micro Frontend Architecture and Demo

Short description:

Aquí tenemos una interfaz de usuario con dos características independientes, un chat y un perfil de usuario. Cada equipo puede implementar estas características de forma independiente construyéndolas y desplegándolas en un CDN. Utilizamos webpack y module federation para obtener las dependencias e integrarlas en tiempo de ejecución. Tenemos un almacén ligero para compartir el estado entre los micro frontends, colocando la lógica del estado dentro de cada aplicación. En una demostración, mostramos cómo se cargan diferentes árboles de componentes y dependencias basados en el contexto de la aplicación.

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.

3. Montando la Aplicación y Limpieza

Short description:

Recibo una URL, cargo scripts y monto la aplicación en un elemento HTML, devolviendo una función de desmontaje para la limpieza.

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

4. Desacoplando Aplicaciones y Creando Límites

Short description:

Desacoplamos nuestras aplicaciones utilizando micro frontends para crear límites. Al renderizar cada aplicación en su propio árbol de componentes, evitamos dependencias de contexto implícitas. Utilizamos un almacén ligero llamado proveedor ReactiveMap para compartir estado entre aplicaciones. Esto nos permite cambiar partes específicas de la aplicación sin afectar a otras. Incluso podemos combinar diferentes frameworks, como reemplazar React con Vue, simplemente cambiando la ubicación de renderizado. Esto nos brinda flexibilidad y la capacidad de crear límites.

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.

5. Creando Límites y Demostración de Rendimiento

Short description:

Tengo este Vue.js dentro de la aplicación Next.js, y en realidad reacciona a los cambios. Creamos límites entre nuestras aplicaciones y tenemos contratos explícitos. Preparé una demostración para abordar las preocupaciones de rendimiento. Tengo una aplicación React que puede montar muchas otras aplicaciones. Hagamos un experimento con 30,000 componentes y veamos cuánto tiempo tarda en renderizarse.

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.

6. Rendimiento de Renderizado de Múltiples Aplicaciones

Short description:

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. ¿Qué aprendimos aquí? Fue más rápido. 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 será. En resumen, esto no hará que tu aplicación sea más lenta. 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.

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.

7. Compartiendo Estado y Usando Contratos Explícitos

Short description:

Puedes crear múltiples árboles de componentes y usar contratos explícitos para compartir estado o contexto. Mantén la lógica del estado dentro de los límites y evita el uso de herramientas poderosas como Redux y Recoil para la comunicación entre aplicaciones.

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.

QnA

Estilos y Contratos de Micro Frontend

Short description:

¡Muchas gracias! Gracias. Gracias. ¿Micro frontends, eh? Tenemos una pregunta del público. Quieren saber cómo asegurarse de que los estilos no se mezclen entre aplicaciones y cómo hacer cumplir los contratos entre diferentes microaplicaciones. Buenos consejos son dar un espacio de nombres a tus estilos y evitar el uso de estado global. Las comprobaciones en tiempo de ejecución y TypeScript pueden ayudar a hacer cumplir los contratos. En cuanto a renderizar múltiples aplicaciones con componentes, comenzar a pintar antes puede hacerlo más rápido. La elección de herramientas depende del contexto y los requisitos. Es importante no usar demasiadas laptops y frameworks simultáneamente. La decisión de adoptar la arquitectura de Microfrontend en Hoppin y su impacto en los equipos y desarrolladores es un tema interesante.

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

Trabajando de forma independiente y Gestión de estado

Short description:

Cuando me uní hace nueve meses, mi departamento tenía 12 ingenieros en una aplicación Exodus. Ahora somos alrededor de 60. Necesitábamos una forma para que las personas trabajen de forma independiente. Operamos con toma de decisiones de abajo hacia arriba y construimos nuestro propio marco de trabajo. Estamos desarrollando una herramienta simple de gestión de estado. Esperamos poder hacerla de código abierto en el futuro. Sigue a Alex en Twitter para obtener actualizaciones. No hay más preguntas, pero habrá una sala de discusión más tarde.

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!

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
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
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 Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

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 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn