Construcción de Módulos Federados Multiplataforma con React, React Native y Re.Pack

¡Muchas gracias y hola a todos! Esta es la primera vez que hablo en este disco silencioso así que se siente un poco interesante. Y tengo un montón de anuncios que hacer pero veremos si tenemos suficiente tiempo durante la sesión de preguntas y respuestas. Bien, así que hoy, como pueden ver, el tema es construir super apps multiplataforma con React, React Native y Reapack. Así que antes de comenzar, un par de palabras sobre mí. Esa es una foto más precisa de mí porque la púrpura que han visto fue hace como seis meses. Soy CDO y fundador de ColdStack. He estado trabajando con React Native durante 10 años. Pueden encontrarme bajo Grubhub en casi todas partes. Y solo puse esta captura de pantalla porque me di cuenta cuando la estaba haciendo, han pasado más de 10 años y es bastante interesante que cuando se trata de escribir código en React Native, cuando estaba escribiendo esto, me preguntaba cuándo este código se convertiría en legado. Y me acabo de dar cuenta de que puedo recordar que el código que escribí ya es legado, lo cual es una realización bastante interesante como el tiempo vuela tan rápido.

De todos modos, hoy quiero hablarles sobre micro-frontends. Puede que hayan escuchado el término super apps pero quiero hablar sobre micro-frontends que es cómo pueden aprovechar la federación de módulos para construir aplicaciones verdaderamente multiplataforma, de hecho, convertirlas en plataformas con código de terceros incluido si ese es también su caso de uso. Y el tema originalmente era sobre super apps, pero encuentro que los micro-frontends son más útiles, de propósito más general, un término más amplio que no necesariamente se aplica solo a super apps. Así que echemos un vistazo a lo que tenemos en la agenda hoy. Primero, haré una pequeña introducción a Repack y React Native. Así que tal vez solo para obtener una mejor comprensión de la audiencia, ¿cuántos de ustedes son desarrolladores de React Native? Bien, y así aquellos de ustedes que no levantaron la mano, supongo que son desarrolladores de React. Bien, veo algunas manos moviéndose, está bien, de acuerdo. Así que intentaré hacer esta introducción suave y luego hablaremos sobre Repack, qué es, una visión general de alto nivel, y luego hablaremos un poco sobre la federación de módulos y luego obviamente los beneficios y cosas de las que no hablamos durante esos 30 minutos. Así que vamos, comencemos.

Tradicionalmente, cuando se trata de contenido dinámico, típicamente teníamos opciones limitadas en el móvil. WebViews eran la solución rápida, ¿verdad? Esencialmente incrustar un navegador en su aplicación y esto es genial cuando quiere enviar mucho contenido dinámico sin afectar el tamaño general de su aplicación, pero también esto viene con una experiencia de usuario degradada y obviamente problemas de rendimiento. Empresas como Shopify, esto se toma de su artículo, usan WebViews en más de cientos de lugares, muy importantes pero no críticos para la misión. Como las pantallas que pueden ver en las diapositivas, muy dinámicas, y también gastan muchos recursos de ingeniería para asegurarse de que esos problemas no afecten la experiencia de usuario. Como aquí, comparten en Twitter cómo solucionan problemas de rendimiento, cómo hicieron que WebViews sean hasta seis veces más rápidas, y podríamos hacer todo eso o podríamos usar la federación de módulos y esto es exactamente de lo que vamos a hablar hoy. Entonces, ¿qué es la federación de módulos? Para entender mejor eso, volvamos en el tiempo y hablemos un poco sobre la división de paquetes. Estoy seguro de que han escuchado sobre esto antes. La división de paquetes es una especie de estándar de facto en estos días. La idea es muy simple. Dividimos nuestro código en fragmentos y los cargamos bajo demanda según sea necesario, y en ese entonces, esto era bastante revolucionario. De repente no tenía que enviar un solo paquete, podía dividir su paquete en múltiples fragmentos, y luego, cada vez que realizara un cambio, solo actualizaría, digamos, el fragmento del cliente o tal vez el fragmento del proveedor.

Y por cierto, ustedes no pueden ver esto, pero es como si la mitad de ustedes estuviera tratando de tomar un poco de aire fresco. Es bastante interesante. Estoy tratando de no distraerme con eso, pero es realmente interesante porque todo está fluyendo, sincronizado, y esta vista detrás es un poco intimidante también. Es bastante interesante. De todos modos, bien.

Así que eso ayudó con el almacenamiento en caché y la versionado porque de repente, como dije, podías dividirlo todo. Y luego la federación de módulos, lo que realmente hace es llevar esto un paso más allá. En lugar de dividir una aplicación en fragmentos, de repente puedes tener múltiples aplicaciones independientes trabajando juntas. Como en este caso, la aplicación anfitriona, siempre que incluya un runtime de federación de módulos, puede comenzar a incluir múltiples aplicaciones remotas más pequeñas que puedes agregar durante el ciclo de vida de la aplicación. Puedes actualizarlas, o incluso puedes eliminarlas. Y la diferencia clave con la división de código es que los módulos federados, o esas aplicaciones remotas, son totalmente independientes de la aplicación anfitriona.

Así que a diferencia de la división de paquetes, puedes modificar la lista de esos remotos sin realmente afectar a la aplicación anfitriona, sin tener que volver a desplegar eso. El anfitrión realmente los descubrirá y cargará en tiempo real durante el tiempo de ejecución. Así que hoy, la federación de módulos, como ya sabemos, evolucionó desde la división de paquetes y ahora está empezando a convertirse en un concepto independiente del empaquetador. En 2024, se convirtió en toda una especificación, y hay empaquetadores fuera del ecosistema de Webpack que están comenzando a soportarlo, incluyendo RSPack y Roldown también. Así que ahora la pregunta es, ¿podemos llevarlo a React Native? Después de todo, React Native ejecuta JavaScript.

Tiene un sistema de módulos, así que teóricamente, todo debería ser posible, ¿verdad? La respuesta es, por supuesto, sí, de lo contrario no estaría aquí. Y la respuesta a eso es Repack, que es un empaquetador alternativo para React Native. Puedes pensar en él como una pequeña capa de compatibilidad sobre Webpack. Compatibilidad, sí. Ahí lo tienes. Sobre Webpack o RSPack en este caso, llevando lo que ya está allí al mundo móvil.

¿Y por qué creamos Repack en primer lugar? Bueno, primero que todo, es bueno tener opciones. Los empaquetadores alternativos proporcionan más diversidad y nos desafían a entregar más rápido y a idear más ideas como colectivo. Y Repack utiliza RSPack bajo el capó. Y hay otros proyectos donde puedes usar Vite, por ejemplo, para construir aplicaciones de React Native también. En segundo lugar, vemos un gran valor en poder compartir infraestructura. Cuando comienzas a compartir código entre React, React Native, de repente tienes más de cinco plataformas. Y es bastante útil compartir los mismos conceptos, plugins y transformaciones con los que estás tratando en diferentes lugares. Y por supuesto, tiene soporte para la federación de módulos de forma nativa.

Así que porque lo tenemos, podemos simplemente comenzar a usarlo. Así que puedes estar pensando, ¿dónde está el truco? React Native, a diferencia de otros frameworks, ha estado trabajando exclusivamente con Metro. Y debe haber una razón para eso. ¿Qué perdemos si optamos por Repack? ¿Dónde está el truco? ¿Vamos a perder rendimiento? ¿Es un reemplazo directo? ¿O hay quizás un bloqueo de proveedor? Así que a un nivel alto, quería desglosar el concepto de empaquetado en el mundo de React Native para mostrarte cómo Metro Bundler toma múltiples archivos fuente y crea este paquete, paquete IIFE, que invoca inmediatamente la expresión de función.

Lo que hay dentro del paquete son obviamente polyfills de React Native, así que todo lo necesario para que el código de React Native se ejecute. El tiempo de ejecución de Metro, que es el __d, __r, y __hmr, así que todo para la declaración de módulos y requiere, así como __hmr. Y obviamente el código de la aplicación justo ahí. Y así, en teoría, puedes construir una aplicación de React Native con cualquier empaquetador de tu elección, siempre que proporciones un tiempo de ejecución compatible que satisfaga los requisitos de React Native que espera del paquete. Y eso es lo que Repack realmente hace en este caso. Y por supuesto, Repack es tan bueno como el empaquetador subyacente.

Y durante muchos años, estuvimos jugando al juego de ponerse al día con Metro, que obviamente estaba altamente optimizado para React Native. Así que cada vez que teníamos esta discusión, oye, deberías usar la federación de módulos, alguien estaría preocupado por el rendimiento o, ya sabes, la lista de desafíos era bastante impresionante y larga. Y afortunadamente, con el lanzamiento de Repack V5 hace un par de meses, la brecha se ha cerrado dramáticamente. Pudimos migrar desde RSPack, que es un empaquetador compatible con webpack basado en RAS. Y como puedes ver, pudimos reducirlo de 7 segundos a 1.75, lo cual es una mejora de alrededor de cinco veces.

Dicho esto, ahora tenemos todas las piezas en un solo lugar. Tenemos federación de módulos de alto rendimiento, __hmr, lo que significa una gran experiencia para el desarrollador. Y obviamente podemos cambiar los empaquetadores sin bloqueo. Porque como te acabo de decir y mostrar, es una capa enchufable que, teóricamente, puedes intercambiar sin. No es como un boleto de ida. Así que exploremos cómo podemos aprovechar esta arquitectura para construir micro-frontends multiplataforma y lo que realmente es en la práctica. Así que antes de entrar en eso, aquí hay una pequeña visión general de una arquitectura de aplicación federada. Esto es algo agnóstico a la plataforma, lo mismo se aplica para web y móvil.

Si has trabajado con la federación de módulos antes, esto quizás te resulte muy, muy familiar. Y acabo de ver que el temporizador comenzó ahora mismo. De repente, ocho minutos. Estoy seguro de que probablemente esté mal. Lo que sea. De todos modos, en este escenario, hay tres equipos lanzando tres aplicaciones en paralelo. Diferente conjunto de características, diferente conjunto de requisitos. Lo que sucede después es que estas tres aplicaciones separadas se combinan juntas con un contenedor. Y eso es lo que constituye típicamente un sitio web en este caso.

Si echamos un vistazo a una aplicación móvil típica, en este caso Uber, podríamos imaginar Rides y Eats siendo esos módulos federados. Típicamente, es una aplicación independiente, pero luego en algún momento, se unirían para formar la aplicación de Uber. Y si recuerdas, o si tuviste la suerte, algunas geolocalizaciones tenían Uber Eats como una aplicación independiente separada. Así que eso realmente prueba que deben haber tenido una arquitectura similar bajo el capó para cambiar sin problemas entre esas experiencias separadas e integradas. Así que si intentamos desglosar esto en una perspectiva más técnica, podemos pensar en cada módulo como una aplicación de React Native independiente, con React Navigations Navigator en la parte superior. Es simplemente independiente, por lo que obviamente podemos encenderlo, puedes ejecutarlo, puedes mostrar el navegador predeterminado.

Sin embargo, cuando lo presentas como una ruta por otro módulo, comienza a actuar como un navegador anidado. Así que en la práctica, aquí hay una especie de implementación hipotética de cada uno. Como puedes ver, cada módulo federado exporta un punto de entrada, que es un componente de React Native para renderizar. Eso puede ser cualquier cosa, en nuestro caso, como te mostré antes, va a ser un navegador. Y aquí en la diapositiva, tenemos algunas pantallas anidadas que, teóricamente, la aplicación de Uber podría estar usando, como la lista de restaurantes o los detalles del restaurante. Luego, para cargar esos módulos desde dentro del host, todo lo que tenemos que hacer es simplemente importarlos. La importación dinámica es procesada por Repack y el plugin de federación de módulos y reemplazada con una ubicación real del módulo. Y los módulos disponibles, junto con su ubicación, obviamente pueden configurarse en la configuración.

Y antes de mostrártelo, vale la pena señalar que esta configuración es bastante flexible y depende de tu configuración y requisitos. En este caso, dado que Repack utiliza RSPack bajo el capó, realmente no estamos configurando Repack. Estamos configurando RSPack con los plugins proporcionados por Repack para que funcione con React Native y satisfaga los requisitos. Tiene pocas opciones, pero la que realmente queremos discutir hoy es remotes. Ahí es donde hemos definido nuestros módulos. Como puedes ver, tenemos eats y rides, y estos dos provienen de CDN. Ya fueron creados, desplegados independientemente, por equipos separados. Realmente no nos importa de dónde provienen.

Sin embargo, tenemos un módulo adicional en el que estamos trabajando junto con nosotros, en paralelo con la aplicación host, rental. Y estamos cargando este desde la fuente, lo que significa que hay un servidor RSPack ejecutándose en algún lugar de nuestra máquina. Y podrías estar pensando, ¿cómo llevamos esos chunks al CDN? Y la buena noticia para mí es que esto está fuera del alcance de Repack, pero la mala noticia para ti es que necesitas implementar algún tipo de infraestructura para que funcione. Y afortunadamente, hay un proveedor listo para usar llamado Zephyr Cloud que hace justamente eso y algunas características más. Lo que hace es que realmente se encarga de todo el versionado, hashing y seguridad.

Así que puedes simplemente subirlo como a NPM y olvidarte de todo lo demás. Y funciona con React y React Native, lo cual, creo, es genial. Así que, como dije, así es como lo configuras. De ahí vienen los eats y rides. Volviendo a los módulos. Cada módulo exporta un React Navigations Navigator de nivel superior, así que importamos los navegadores. Y debido a que Module Federation se integra perfectamente con las características de React para la carga diferida, podemos simplemente envolverlo con suspense, proporcionar algunos fallbacks, y boom, tenemos un estado de carga para cada una de las pantallas. Podemos ajustarlo más tarde, pero en principio, es así de fácil proporcionar ese estado.

El paso final realmente depende de tu configuración, pero dado que estamos usando React Navigation, simplemente estamos colocando cada uno de esos navegadores de nivel superior de los módulos federados como pantallas dentro de la aplicación host. Así que cada vez que queramos mostrar uno de esos módulos federados, simplemente podemos empujar el módulo relevante y será descargado, cargado y mostrado. Si estás interesado en experimentar con esta configuración, puedes escanear el código QR. En nuestro GitHub, tenemos exactamente esa configuración en funcionamiento, así que puedes clonarla, puedes instalar dApps, y estás listo para comenzar.

Hasta ahora, hemos estado hablando principalmente del flujo regular, pero lo interesante es el flujo para desarrolladores de terceros, o tal vez si eres una organización realmente grande y tienes tantos equipos que cuando los encuentras en la cocina, dices, no te he visto antes. En ese caso, esto también se aplicará a ti. Así que imaginemos que realmente estamos construyendo una aplicación de Uber, y un caso de uso muy típico es que vamos a incluir alquileres. Pero no vamos a proporcionar los alquileres, ¿verdad? Hablaremos con una de esas compañías de alquiler como Hertz, ellos proporcionarán alquileres desde su API. Típicamente, lo que hacemos es hablar con el desarrollador de terceros, le pedimos a Hertz sobre sus documentos de API, sobre todo lo que tienen, y luego vamos e implementamos todo. Haremos manejo de errores, haremos gestión de estado, haremos integración de UI, todo tipo de cosas que se requieren, y luego al final, haremos la integración real que estará estrechamente acoplada con nuestra aplicación.

Pero, ¿y si hubiera una manera diferente de hacer esto? Bueno, imaginemos un escenario donde no lo implementamos, sino que alguien más lo implementa por nosotros, lo cual es obviamente el mejor caso. Así que proporcionamos un SDK que incluye herramientas de desarrollo, documentos de API, estándares, y todo lo que proporciona nuestro entorno, y luego los desarrolladores externos implementan características reales siguiendo nuestros requisitos de UI, nuestros estándares, nuestra seguridad, nuestras herramientas, todo. Lo que tienen que crear al final del día es solo esta mini aplicación que funciona de manera independiente, cumple con los requisitos de su negocio, sus requisitos comerciales, nuestros requisitos, es independiente. Es un cambio diferente, es un cambio significativo del enfoque anterior porque no está acoplado a nuestra aplicación. Y lo que sucede después es que cuando están listos, nos lo envían a través de cualquier sistema que hayamos establecido, y eso se convierte en parte de nuestra aplicación automáticamente. Y la buena noticia es que esto es exactamente de lo que trata Module Federation, y puedes construirlo hoy en React Native con Reapak. Así que echemos un vistazo rápido a cómo podemos implementar rápidamente cosas como SDK. Esto se basa en el principio de que React Context funciona a través de los límites de la aplicación host y la mini aplicación. Así que a un nivel alto primero, creamos un paquete SDK que exponemos a los desarrolladores externos. El paquete SDK es algo como una declaración de interfaz de lo que se proporciona en tu entorno, y una de las formas más simples de hacer esto es crear React Context. Luego, la aplicación host utiliza el proveedor de contexto para inyectar los valores reales, así que una inyección de dependencia clásica. Y luego la mini app usa hooks o consume el contexto, obteniendo lo que sea proporcionado por el host en un momento dado como el valor real. Así que repasemos esto paso a paso, mirando el Módulo de Pagos, por ejemplo. Así que como dije primero, creamos contexto. Abstracción elegante y simple, fácil de comenzar. Podemos proporcionar algún manejo de errores, por si acaso está mal configurado, y potencialmente un hook para que sea más fácil para las personas trabajar con él. Luego podemos crear un proveedor de tiempo de ejecución de SDK, típicamente lo que hago yo mismo es crear uno y encapsular todo dentro para que sea más fácil para mí seguirlo. Y este es el componente que debe ser proporcionado por el host para ejecutar todas las mini apps. Así que es como un entorno del sistema si quieres ejecutar mi mini app, necesitas proporcionar exactamente esto. Y luego el host tiene que proporcionar valores reales para cada propiedad requerida por el proveedor de tiempo de ejecución de SDK de lo contrario no será visto por el módulo federado.

Como puedes ver, el módulo federado, como su navegador por ejemplo, se renderiza dentro del proveedor de tiempo de ejecución de SDK. Y dentro del módulo federado, muy simple, leemos el valor del contexto y hacemos lo que queramos con esa API. Los beneficios, unos cuantos. En primer lugar, esta arquitectura te permite hacer un control de acceso detallado muy fácilmente. Por ejemplo, puedes delimitar y pasar todas las llamadas a través del SDK. Puedes decidir si ciertas APIs están disponibles o no. Requerir aprobación previa del usuario. En este caso, por ejemplo, es un concepto muy simple donde puedes simplemente requerir que el permiso esté presente antes de continuar. Y estoy como simulando la alerta real de iOS pero puede ser cualquier cosa realmente.

La arquitectura aquí no es prescriptiva. Puedes decidir cómo quieres que se comporte, cómo quieres que sea, pero es un concepto bastante universal. También puedes proporcionar un sandbox fácil para tus testers o desarrolladores externos. La aplicación host, después de todo, no es más que una aplicación de React Native que proporciona valores reales para el proveedor de tiempo de ejecución de SDK. Así que podemos crear tantos como quieras y proporcionar tantos valores diferentes para esos contextos, diferentes contextos como quieras. De esa manera, puedes crear uno de producción, puedes crear uno de desarrollo, y tal vez uno para terceros que tenga versiones simuladas. Algo muy simple.

Y otra idea interesante es la interfaz de usuario multiplataforma, que hace que tu módulo federado sea verdaderamente independiente de la plataforma. Puedes proporcionar componentes de UI como vista, texto y botón, y puedes decidir qué tipo de UI se renderiza dentro de cada uno de esos módulos federados. Esto puede ser componentes, puede ser estilo, cualquier cosa realmente, depende de cómo pienses sobre la UI multiplataforma. Pero este código se ejecutará en todas partes. Así que si usas módulos federados en React Native y React, este código se ejecutará prácticamente en todas partes. Los casos de uso que no están cubiertos, todo lo que tendrás que hacer por tu cuenta.

La primera es el portal de desarrollo. Así que si esta charla está resonando contigo, algunos de ustedes probablemente se estén preguntando sobre cómo aceptamos esos módulos externos, ¿usamos GitHub para eso, alojamos una solución con UI como el portal de desarrollo al estilo de Apple? Y la respuesta es, depende obviamente. Solo quiero mostrarte, y una pequeña advertencia, esta será una diapositiva blanca. Este es un diagrama muy complejo que muestra el proceso de toma de decisiones y todos los pasos que ocurren cuando se revisa una mini-app por una empresa llamada Momo de Vietnam. Es una super app local que está usando React Native. Usan este concepto para integrarse con terceros. Tienen todo un portal de desarrollo para eso con guías y proceso de envío. Así que no es prescriptivo, típicamente esas empresas no comparten su código con la comunidad. Y finalmente, tenemos los desafíos relacionados con JavaScript en sí alrededor del código de terceros. Escuchamos esta pregunta bastante de las empresas. Sabes, el desafío es que cuando comienzas a cargar esos diferentes módulos federados en un único contexto compartido de JavaScript, es muy probable que uno de los fragmentos tenga algún código malicioso y es posible hacer ingeniería inversa o romper tu aplicación, lo cual no es deseado.

En este caso, tengo este ejemplo muy simple donde estamos modificando el prototipo, honestamente, y como puedes ver cuando haces un console log, se proporcionará una salida diferente, no un nombre de usuario real. Así que esto es solo un ejemplo, pero un ejemplo más del mundo real que puedo decir es una de las empresas con las que hemos estado prototipando esto y enviamos este concepto tiene un dispositivo de hardware que recopila datos sensibles, pero también permiten que mini-apps más pequeñas se ejecuten juntas allí. Y la preocupación es cómo nos aseguramos de que ninguna de las mini-apps pueda interferir con los datos sensibles y eso es en el ámbito de la salud. Así que como puedes imaginar, las preocupaciones son realmente, realmente altas. Puedes mitigar esto haciendo muchas cosas, pero uno de los enfoques más populares, fáciles y probablemente más fuertes es separar un par de módulos federados a diferentes entornos de React Native, por lo que tendrías múltiples instancias de Hermes Engine que estarían ejecutando código de React Native por separado entre sí y controlarías cómo se comunican entre sí. Para eso, puedes utilizar una API similar a postMessage, por ejemplo, que es cómo nos comunicamos a menudo.

Quiero decir, quiero decir a menudo, pero quizás nadie está haciendo eso para la comunicación de iframe a ventana principal ya, pero si has estado construyendo iframes, recuerdas que hay una API postMessage en Windows que puedes usar. Podría verse típicamente así. Tendrías APIs de sendMessage y receiveMessage y luego en este caso, lo que hacemos es permitir enviar mensajes a cualquiera de los módulos de componentes registrados y si recibes un mensaje desde cualquiera de estos componentes, ese callback estará limitado al módulo desde el que se está ejecutando el código. Así que si el mensaje recibido se llama desde cualquier lugar del módulo B, dentro del módulo B, ese código solo podrá recibir callbacks del módulo B, lo cual es bastante útil cuando realmente quieres ese nivel de separación. Así que para resumir, algunos de los puntos clave de esta charla. En primer lugar, no necesitas... Las super apps no son webviews. Ya no necesitamos incrustar navegadores completos en nuestras aplicaciones móviles para construir super aplicaciones con React Native. Gracias a Module Federation, ahora podemos comenzar a adaptar React Native para super apps y gracias al entorno de JavaScript, podemos desbloquear ciertos patrones que son muy difíciles de hacer de forma nativa como la carga dinámica de código y cosas así.

Y no se limita solo a super apps, en realidad puede hacer que tu base de código sea más modular, puedes permitirte enviar más rápido, puedes de alguna manera desacoplar tus equipos. Si tus equipos son altamente independientes, esto es a menudo una extensión interesante para tu base de código. Puedes incorporar características de terceros con SDK en tiempo de ejecución en cualquier momento, como has visto, es bastante fácil adaptar este enfoque de SDK y de repente tu aplicación se convierte en una plataforma y es una aplicación multiplataforma por defecto, funcionando tanto en web móvil como posiblemente en otras plataformas. Y si piensas que esto es algo que lleva mucho tiempo, típicamente ese enfoque puede probarse en producción en una semana. Así que si estás pensando en este enfoque, estoy feliz de hacer una demostración para ti o simplemente puedes escanear este código QR. Para nosotros, como creadores de Repack y defensores de empaquetadores alternativos en React Native, cuantas más empresas comiencen a usar eso, mejor. Y creo que con Module Federation realmente podemos hacer nuestras aplicaciones más rápidas y simplemente enviar más rápido con características más interesantes. Eso es todo, gracias.

Sí, así que primero antes de que lleguemos a tal vez una o dos preguntas que tenemos, felicidades por más de 10 años trabajando en esto. No quiero sentirme tan viejo. Quiero decir, al menos somos igual que React Summit. Ha cambiado bastante desde la primera conferencia. Vamos a averiguarlo. Bien, así que creo que tenemos tiempo para tal vez una o dos preguntas. Así que no olvides las preguntas en el Slido. También puedes votarlas. ¿Quieres dejar que los oradores sepan qué preguntas necesito hacerles? ¿Quién tuvo tantos segundos? Ese soy yo. Bien, de acuerdo. Creo que tenemos bastantes preguntas sobre el tipo de implicaciones de rendimiento y cómo lidiar con la sobrecarga. Así que, por ejemplo, ¿hay una manera de o cuál es tu enfoque para lidiar con el compromiso de todas estas diferentes cosas para descargar? ¿Cómo estructuras las cosas para que no obstruyas la experiencia del usuario? Sí, tienes que ser inteligente sobre cómo divides esas cosas. Un gran ejemplo que puedo proporcionar aquí es mi caso de uso favorito porque me gustan los coches, uno de los clientes es una aplicación de coches. Así que típicamente cuando abres, digamos, una aplicación de BMW y voy a usar este ejemplo porque está en Flutter, así que es el 100% de esta aplicación. Pero cuando la abres, ves una pantalla de carga, ves algunas características comunes. Así que estas típicamente las precargas con la aplicación. Así que si recuerdas la configuración, algunos de los módulos pueden venir de forma remota, pero algunos de los módulos pueden estar empaquetados juntos, así que no tienes que enviarlos de forma remota. Pero luego cuando inicias sesión, cuando configuras o descargas algunos datos de la API, este es el momento en el que puedes comenzar a obtener esos módulos sin obstruir la experiencia del usuario. Por ejemplo, basado en el número VIN, puedes descargar las características que afectan a ese usuario en particular.