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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at React Advanced 2021, check out the latest edition of this React Conference.

FAQ

Los micro frontends son una arquitectura que considera las aplicaciones como una colección de aplicaciones más pequeñas, cada una organizada en torno a capacidades empresariales, propiedad de un equipo pequeño, independientemente desplegables y débilmente acopladas.

Hoping organiza sus micro frontends por áreas de productos, donde cada equipo trabaja de manera independiente en características específicas que pueden desplegar y construir de forma independiente, usando tecnologías como React y Vue.

Los micro frontends permiten a los equipos trabajar de forma rápida y autónoma, evitando interferencias entre ellos, lo que facilita la escalabilidad y la gestión de múltiples equipos y tecnologías en un solo proyecto.

Hoping utiliza un almacén muy ligero para permitir que los equipos compartan algo de estado, pero generalmente desalienta compartir estado entre micro frontends para mantener un diseño desacoplado.

Se recomienda dar un espacio de nombres a los estilos y evitar el uso de estado global para prevenir conflictos, especialmente en aplicaciones que usan selectores globales.

Hoping combina tecnologías como React y Vue en sus productos, permitiendo a los equipos desplegar sus características independientemente y utilizar webpack para la integración de estas tecnologías.

Hoping realiza pruebas de rendimiento para asegurarse de que el uso de múltiples micro frontends y componentes no afecte negativamente la eficiencia, manteniendo una gestión de estado simple y desacoplada.

Alex Lobera
Alex Lobera
25 min
22 Oct, 2021

Comments

Sign in or register to post your comment.
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.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Escalando con Remix y Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Escalando con Remix y Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.