1. Introducción a Micro Frontends con React Native
Estoy súper emocionado de estar dando esta charla sobre micro frontends para móviles con React Native. Un poco sobre mí. Mi nombre es Mo. Soy el jefe de móviles en una empresa llamada Theodo con sede en el Reino Unido. Hemos estado haciendo React Native durante mucho tiempo. En los últimos meses, un cliente nos pidió que desarrolláramos un servicio de streaming. Con las aplicaciones universales, la idea es que escribas una vez y puedas ejecutar en cualquier lugar. Intentas reutilizar la mayor cantidad posible de tu lógica de componentes principales y tu lógica de negocio en general. ¿Cómo arquitecturamos un proyecto a esta escala? ¿Cómo creamos la corriente de trabajo correcta para que nuestros equipos puedan desarrollar simultáneamente? Una de las cosas que hicimos fue intentar tomar las principales características de la aplicación y ponerlas dentro de paquetes que los equipos pudieran desarrollar de manera autónoma.
Hola a todos, es un placer estar con todos ustedes en React Advanced este año. Estoy súper emocionado de estar dando esta charla sobre micro frontends para móviles con React Native. Es un tema que he estado explorando un poco durante los últimos meses y creo que hay muchos aprendizajes interesantes y espero que al final de esto haya despertado su interés para explorar un poco más en un área que creo que está un poco subdesarrollada y hay mucho margen para mejorar dentro de nuestra community. Así que sí, espero que salgan cosas emocionantes de esto. Un poco sobre mí. Mi nombre es Mo. Soy el jefe de móviles en una empresa llamada Theodo con sede en el Reino Unido. Theodo es un grupo de consultores internacionales, expertos digitales que están ubicados alrededor del mundo, principalmente en Francia, el Reino Unido, Nueva York y también en Marruecos. Hemos estado haciendo React Native durante mucho tiempo. Es posible que nos conozcan por otro nombre, BAM, donde hemos estado trabajando en open-source en React Native desde el principio. Adoptamos React Native cuando salió unos meses después de que fue lanzado por Meta, y hemos lanzado varios proyectos de open-source como la biblioteca de redimensionamiento de imágenes de React Native, y más recientemente Flashlight, que es una herramienta para medir el performance de las mobile apps. Al estar en el espacio de consultoría, tienes la oportunidad de experimentar muchos proyectos diferentes, y quiero hablarles un poco sobre uno de ellos hoy. Tiempo de historia. En los últimos meses, un cliente nos pidió que desarrolláramos un servicio de streaming. Ahora, esta es una plataforma de medios a gran escala. No es solo streaming con algunos videos y solo un sitio muy básico. Era la cosa completa, con noticias, con streaming, leyendo artículos, escuchando podcasts, todo centralizado en esta única plataforma que tenía muchas características diferentes en movimiento. Los puntos clave en este proyecto eran que, uno, había un gran número de características, pero tenían un montón de otros requisitos que lo hacían más complejo. Uno era que querían que tuviera paridad de características en la web, móvil, e incluso TV. Querían tener un tiempo de respuesta muy corto, lo que significaba que necesitábamos tener varios equipos de desarrolladores trabajando en este proyecto simultáneamente. Entonces, siendo un poco familiar con el espacio de React Native, una de las cosas que buscamos cuando escuchamos sobre la paridad en todos los aspectos fue esta idea de aplicaciones universales. Este es un espacio que se está desarrollando y creo que está llegando a su plenitud en los últimos años. Con las aplicaciones universales, la idea es que escribes una vez y puedes ejecutar en cualquier lugar. Puedes usar React Native realmente para crear una aplicación web, una aplicación móvil, una aplicación de escritorio, e incluso quizás una aplicación de TV. Intentas reutilizar la mayor cantidad posible de tu lógica de componentes principales y tu lógica de negocio en general y es súper poderoso en el sentido de que puedes tener muchos, muchos beneficios en términos de velocidad y entrega y tasa de iteración e innovation. Así que es un espacio muy emocionante en el que estar y sabíamos que iba a ser una buena opción porque nuestro proyecto iba a ser primero para móviles pero también necesitaban acceso a la web y a la TV, así que fue una decisión obvia para nosotros. Pero también nos hizo pensar en algo un poco más sutil, que era cómo arquitecturamos un proyecto a esta escala? ¿Cómo creamos la corriente de trabajo correcta para que nuestros equipos puedan desarrollar simultáneamente? Tenemos decenas de diferentes desarrolladores trabajando en este proyecto al mismo tiempo. ¿Cómo lo organizas de manera que las personas no estén pisándose los pies? Las personas no están teniendo demasiados conflictos de fusión diferentes o demasiados bloqueos diferentes en el camino de su desarrollo. Así que una de las cosas que miramos muy de cerca fue cómo estructuramos este proyecto? Ahora esta es una estructura de carpetas simplificada, pero espero que se entienda el punto. Una de las cosas que hicimos fue intentar tomar las principales características de la aplicación y ponerlas dentro de paquetes
2. Introducción a Micro Frontends
Algunas de las características principales se aislaron en paquetes separados que se podrían utilizar dentro de la aplicación. Este diseño modular basado en características funciona bien para aplicaciones universales y React Native. El siguiente paso natural es explorar microfrontends para móviles. Los microfrontends no son adecuados para todos los proyectos, pero pueden ser beneficiosos para proyectos a gran escala con equipos autónomos. La historia de los microfrontends comienza con la transición de los monolitos a los microservicios en el backend. A medida que las aplicaciones crecen, mantener un frontend monolítico se vuelve desafiante, ralentizando la velocidad de desarrollo.
que los equipos podrían desarrollar de forma autónoma. Así que algunas de las características principales eran cosas como ver transmisiones en vivo o leer artículos de noticias o quizás escuchar un podcast. Y así nosotros aislamos estas características en paquetes separados que luego podrían ser utilizados dentro de la aplicación. Y estos finalmente fueron los bloques de construcción que se unieron y construyeron la plataforma completa. Y una de las cosas agradables acerca de
packaging de esta manera era que podríamos efectivamente tomar cualquiera de estos
modules, aislarlos, probarlos individualmente, podrían ser desarrollados en aislamiento sin necesidad de lidiar con todas las otras cosas con las que los equipos estaban trabajando, lo que significaba que los desarrolladores realmente no se bloquearían en ningún momento. Y este tipo de
design modular basado en características funciona bastante bien para aplicaciones universales y aplicaciones
React Native. Porque cuando comenzamos a desglosar nuestros equipos, vimos que habíamos creado estos agradables verticales de características donde un solo equipo se estaba enfocando en la lógica de negocio en el
frontend, estaban creando componentes comunes de
React Native. Pero también estaban programando en Native para iOS y Android y web y realmente entendiendo el núcleo de la característica que estaban construyendo y convirtiéndose en especialistas en eso. Realmente nos gustó eso, pero no era un concepto nuevo. El siguiente paso natural que podrías tomar de esto era ir por el camino de los microfrontends. Así que despertó esta pregunta en mi mente sobre si los microfrontends para móviles es algo factible. Y eso es lo que vamos a explorar juntos hoy. Esta es una charla muy exploratoria. No estamos buscando... No estoy aquí para abogar por ir a toda máquina con los microfrontends y adoptar ellos para cada proyecto que uses porque eso es absurdo. Creo que hay mucho que podemos aprender de este enfoque. Es aplicable a un tipo muy específico de proyecto. Puede ayudar a muchos proyectos que están a gran escala y son muy, muy grandes y con un gran número de equipos que pueden ser autónomos, pero no es para cada uno proyecto. Así que quiero poner ese grano de sal allí para que todos estén conscientes de que esto no está abogando por que debas usar esto en cada proyecto en el que te embarques de ahora en adelante. Así que vamos a repasar un poco de historia. De los monolitos a los
microservices. Así que irónicamente, la historia de los frontends, la historia de los microfrontends, comienza desde el
backend donde las aplicaciones comenzaron a pasar de los monolitos a los
microservices. Así que digamos que tienes un
backend básico que maneja tres características principales,
authentication, streaming y pagos. Así que están almacenados bajo una aplicación paraguas. Así que todos ellos encajan en una aplicación que es un monolito y eso está bien. Son realmente tres características. No hay mucha superficie, pero naturalmente con el tiempo empiezas a añadir más y más características. Y así la aplicación crece. Y de repente, a medida que este proyecto va creciendo más y más, inevitablemente te quedas con una especie de behemot de una aplicación. Y cada nuevo desarrollador que llega tiene esta carga cognitiva que es simplemente masiva para lidiar con. Y así la velocidad del equipo naturalmente empezará a disminuir a medida que empieces a construir más y más en esta aplicación.
3. Introducción a los Microservicios
Los equipos a menudo caen en el patrón de trabajar en monolitos masivos, lo cual puede ser un desafío. A principios de la década de 2000, surgió el concepto de microservicios como una solución. Los microservicios implican dividir las características de la aplicación en servicios autónomos que pueden comunicarse entre sí a través de APIs o buses de eventos.
Todos lo hemos visto. Es un patrón común en el que caen los equipos. Y te deja sintiéndote un poco como nuestro amigo Harold aquí, trabajando en estos monolitos masivos. Entonces, muchas personas lidiaron con esto a principios de la década de 2000. Y este concepto de microservices comenzó a surgir. Y la idea con esto era, ¿qué pasaría si cada una de estas características de la aplicación comenzara a, se dividiera para constituir su propio servicio autónomo? Entonces, cada uno de estos servicios podría aislarse en divisiones de características muy específicas. Y podrían
4. Explorando Micro Frontends en la Arquitectura Moderna
Los micro frontends son un estilo arquitectónico donde las aplicaciones frontend independientes y entregables componen una aplicación mayor. Permite que diferentes frontends pequeños se desplieguen a su propio ritmo y horario, unidos para construir un sitio completo. El sitio web de Amazon es un ejemplo clásico de micro frontends, con el encabezado, la sección de navegación y las promociones como micro frontends separados. Este enfoque ofrece beneficios como la descomposición de equipos en verticales de características, permitiendo el agnosticismo tecnológico y permitiendo procesos de lanzamiento independientes.
comunicarse con esos servicios, tal vez a través de APIs o algún tipo de bus de eventos. Y si estás mirando el diagrama de la derecha, parece bastante aterrador. Lo es. Pero no para ti. Es para esos pobres ingenieros de plataforma y
DevOps que tienen que lidiar con ello. Así que, estás bien. Esos ingenieros de plataforma van a sentirse como héroes ahora. Así que, no fue la bala de plata que muchas personas buscaban. Pero sí resolvió algunos problemas de escala para muchas grandes organizaciones. Entonces, este concepto de
microservices comenzó a volverse más y más popular. La gente lo adoptaba de izquierda a derecha. Y así, más adelante en el este concepto fue tomado y puesto en el espacio
frontend para crear micro frontends. Ahora, si tú vas al sitio web liderado por la
community para micro frontends, la definición que enumeran allí es que es un estilo arquitectónico donde las aplicaciones
frontend independientes y entregables componen una aplicación mayor. Así que, eso significa que tienes diferentes frontends pequeños y cada uno de estos se despliega a su propio ritmo y en su propio horario y todos se unen y construyen un sitio completo juntos. Y el ejemplo clásico de esto es el sitio web de Amazon. Entonces, Amazon es en realidad un buen lugar para ver dónde podrías dividir los micro frontends. Entonces, si miras la pantalla principal, en la parte superior tienes el encabezado. Eso podría ser un micro
frontend en sí mismo. Tienes la sección de navegación. Eso también podría ser un micro
frontend. Pero entonces también podrías tener estas promociones que tienen en cajas dentro de la parte principal de la página y eso también podría ser un micro
frontend. Y Entonces, cada uno de estos micro frontends compone y construye el sitio web más grande. Entonces, hay bastantes beneficios aquí. Desglosas tus equipos en verticales de características por lo que hay menos contexto para cada equipo. Y realmente pueden lidiar con el núcleo de las características que están construyendo. Eso es genial. Los equipos también pueden ser agnósticos en cuanto a la tecnología. Así que, puedes mezclar y combinar diferentes pilas juntas. Y eso significa que no tienes que llevar realmente la carga de la deuda tecnológica si hay elecciones con las que no estás de acuerdo pero otros equipos podrían haber hecho en el pasado. Todos hemos estado allí. Y cada uno de los equipos tiene
5. Micro Frontends y Aplicaciones Móviles
Los micro frontends añaden complejidad pero ofrecen beneficios como ciclos de lanzamiento independientes. Sin embargo, las aplicaciones móviles tienen procesos de distribución diferentes, requiriendo la presentación a las tiendas de aplicaciones. La arquitectura de React Native permite actualizar la capa de JavaScript sin pasar por la tienda de aplicaciones.
tienen un proceso de lanzamiento independiente. Así, pueden lanzar a su propio ritmo. Y esos lanzamientos serán simplemente cargados lateralmente al usuario cuando y donde esos ciclos de lanzamiento independientes se completen. Así que, esos son los beneficios. Ahora, viene con una desventaja muy importante. Y es que estás añadiendo mucha complejidad para poder lograr esto. Así que, mientras que con un
frontend normal, tienes una sola aplicación que se está publicando. Aquí de repente tienes un montón de partes móviles diferentes. Tienes múltiples con su propia tecnología. Tienes muchos más puntos de fallo con los que vas a tener que lidiar. Y encima de eso, estás añadiendo una capa de host que necesita gestionar la carcasa del
frontend de manera efectiva. Y eso en sí mismo es mucha más complejidad añadida. Y así, esta complejidad añadida es algo que vas a necesitar considerar cuando estés mirando los micro frontends. Y así, cuando llevas esto a la aplicación móvil, bueno, ¿cómo lo dividimos? ¿Podemos encontrar una división similar? Creo que podemos. Si miras la aplicación de Amazon, quizás puedes tener una descripción de producto micro
frontend que es una pantalla de la aplicación. Y puedes también tener un carrito de compras micro
frontend. Así que, puedes empezar a dividir y modularizar una aplicación en micro frontends también. Pero en última instancia, las micro aplicaciones móviles son bastante diferentes a las aplicaciones web. El componente clave aquí es el lado de la distribución. Las aplicaciones se empaquetan y se lanzan a través de una tienda de aplicaciones. Pasas por un proceso de construcción, las presentas a la tienda de aplicaciones. Y así, plantea una pregunta en torno a este concepto de ciclos de lanzamiento independientes. Porque incluso si tomas las diferentes pantallas de las que acabamos de hablar, las pones en módulos, así que, tienes un módulo de detalles de producto y un módulo de carrito de compras, y luego los combinas en una sola aplicación, en última instancia, vas a seguir necesitando pasar por ese proceso de presentación a la tienda de aplicaciones, que es el gran, gran, espantoso fantasma que se encuentra al final de cada lanzamiento del equipo. Y pueden aprobar o negar que tu aplicación pase. Así que, realmente, los equipos futuros no tienen ningún control sobre los procesos de lanzamiento. Y eso realmente envejece a cualquier desarrollador más allá de la medida. Es una vista deprimente de ver. Pero ahí es donde
React Native realmente entra en juego. Y esto es una de las, creo, las bellezas de
React Native es esta arquitectura de tener una capa de
JavaScript y también tener una capa nativa. Y una de las cosas que puedes hacer con eso es que, sabes, si quieres cambiar algunas de las cosas que viven en la capa de
JavaScript de tu aplicación, lo que básicamente puedes hacer es escribir algo de
JavaScript, empaquetar eso, enviar eso a algún lugar en la nube, y la carcasa de la aplicación
React Native puede consultar y básicamente actualizar la capa de
JavaScript cuando quieras lanzar actualizaciones a un equipo. Ahora, esto es increíblemente poderoso porque en cualquier momento tú
6. Micro Frontends con Code Push
Iteraciones más rápidas, correcciones de errores más rápidas, entregando valor a los usuarios antes. Code Push admite un solo paquete de JavaScript, requiriendo agrupar todo junto. Pero, ¿y si pudiéramos usar Code Push en varias partes de una aplicación y agrupar cosas por separado para cada micro frontend? Diferentes instancias de paquetes de JavaScript dentro de una única carcasa de aplicación nativa, desplegadas independientemente por Code Push.
puede simplemente entrar y actualizar
JavaScript sin necesidad de pasar por la tienda de aplicaciones. Iteraciones más rápidas, correcciones de errores más rápidas, en última instancia, entregando valor a sus usuarios antes, todos van a estar más contentos, ¿verdad? Sé que hay muchas implementaciones diferentes para lograr estas actualizaciones en el aire. Pero una es
Code Push que vamos a estar mirando. Y
Code Push es genial. Pero solo admite un solo paquete de
JavaScript, lo que significa que todavía necesitas tomar todo y juntarlo. Lo cual fue una cosa deprimente a la que llegar a términos para mí. Pero aún así me hizo pensar, sería muy genial si pudiéramos usar
Code Push en varias partes de una aplicación y agrupar cosas por separado para cada uno de los diferentes micro frontends que puedas tener y tener diferentes instancias de paquetes de
JavaScript dentro de una única carcasa de aplicación nativa que podría ser desplegada independientemente por
Code Push.
7. Demo de la aplicación MyCars
Pasé bastante tiempo, pero finalmente creamos una demostración para mostrar esto. He creado una aplicación muy básica llamada MyCars con dos pestañas, Inicio y Remoto. Estos son dos paquetes de JavaScript diferentes, dos aplicaciones de React Native desplegadas de forma independiente. Vamos a hacer algunos cambios para mejorar la aplicación, comenzando con la pantalla del tablero.
Pasé bastante tiempo, pero finalmente creamos una demostración para mostrar esto. Y esto es muy emocionante para mí, así que espero que no falle. Echemos un vistazo a la demostración. He creado una aplicación muy básica aquí llamada MyCars. No soy dueño de ninguno de estos coches que estoy a punto de mostrarles. Si nos adentramos en ella, es una aplicación muy básica con dos pestañas. Ahora, la carcasa de la aplicación es una aplicación Swift, pero las pantallas interiores van a ser construidas con React Native. Esta primera pantalla es la pantalla de Inicio, y eso es un solo paquete. Y luego también tenemos una pantalla Remota, que es otro paquete. Estos son dos paquetes de JavaScript diferentes. Son dos aplicaciones diferentes de React Native que se están desplegando de forma independiente una de la otra. Vamos a hacer algunas ediciones para simplemente mostrar cómo funcionaría esto. En la pantalla de Inicio ahora mismo, tengo un pequeño carrusel que tiene un montón de coches diferentes que desearía tener en mi garaje, pero no los tengo. Y un Audi A4, un Bentley Continental, y lo mejor de todo, un Opel Corsa de 1970 con 203.000 millas. Así que tenemos algunos coches de buen aspecto aquí, se los prometo. Vamos a entrar y hacer algunos cambios. Ahora tengo un poco de feedback sobre esto, cómo podemos hacerlo un poco mejor. Así que en primer lugar, buenos días. Siempre dice buenos días. Probablemente no sea exacto en este momento en que estoy grabando esto, cuando es por la noche. Así que vamos a cambiar eso. Y luego también en esto, es un poco confuso en el remoto porque dice vehículo abierto, pero esto es en realidad solo cerrado y abierto. Así que tuve un susto en un momento pensando que los coches se habían quedado con las puertas abiertas cuando solo estaban desbloqueados. Así que vamos a cambiar esas dos cosas. Así que si yo abro esto aquí, tengo un repositorio configurado para la pantalla del tablero, y eso es un repositorio independiente de React Native. Si literalmente miras aquí, todo lo que tenemos dentro de este repositorio es una aplicación básica de React Native que tiene un index.js básico con una aplicación que se exporta, que es simplemente la única pantalla para el tablero. Y de manera similar, aquí, tenemos algo muy similar para la pantalla remota. Así que vamos a entrar aquí y hacer algunos cambios. Empecemos con nuestro tablero.
8. Actualizando Texto y Desplegando Paquetes
Hagamos algunos cambios en el texto de la pantalla principal y la pantalla remota. Activamos un code push para generar y desplegar los paquetes. El desafío es que code push no admite múltiples paquetes de JS, por lo que modificamos su implementación para manejar diferentes paquetes. Al comparar los nombres de los archivos, nos aseguramos de que se acceda al paquete correcto. Después de un code push, cerramos la aplicación y al reabrirla, se activa la actualización, lo que resulta en el texto actualizado y el vehículo desbloqueado en la pantalla.
Entonces, en primer lugar, queríamos cambiarlo de buenos días. Simplemente hagámoslo, ¿cómo estás hoy? Y simplemente cambiaremos el texto allí. Y luego al mismo tiempo en la pantalla remota, dijimos que en realidad no queremos que esté cerrado o abierto. En realidad solo queremos cambiar esto a desbloqueado. Así que vamos a hacer eso. Y luego lo que vamos a hacer es vamos a activar un
code push aquí. Así que tengo un script aquí que ejecutará una generación de el paquete. Y luego, de la misma manera aquí, vamos a hacer un
code push aquí, que generará el paquete, y luego hará una llamada a App Center para efectivamente empujar estos paquetes a la
cloud. Así que eso está haciendo eso ahora mismo, va a hacer una liberación.
Y entonces, si vamos al lado nativo del código, solo he tomado algunos de los fragmentos de código. Esto es muy POC y muy borrador, pero solo para darles una idea, la forma en que funciona es que tenemos un controlador de vista React Native. Y este controlador de vista utiliza la URL del paquete de code push para acceder a un recurso específico. Y ese recurso va a ser pasado por las vistas de las pestañas para decir, sabes, quiero acceder a la pantalla del tablero o quiero acceder a la pantalla remota. Ahora, el desafío aquí es que code push, como mencioné, no admite múltiples paquetes de JS. Entonces, con mucho dolor, una de las cosas que tenemos que hacer aquí es realmente entrar y cambiar cómo code push busca el paquete, cómo code push busca la URL del paquete para un paquete específico que pasas aquí. Entonces, cuando realmente llamamos a code push.bundle URL y pasamos el recurso, necesitamos entrar y modificar la implementación real para que realmente verifique y se asegure de que no está consultando el mismo archivo. Entonces, siempre asume que tienes un paquete. Y en este proceso, lo que hemos hecho es que hemos entrado y lo hemos cambiado para que verifique el nombre del archivo real y los compare. Esto es muy bruto, muy crudo. Es solo para hacerlo funcionar con los dos paquetes diferentes. En última instancia, lo que necesitará suceder aquí es que necesitará poder manejar esto de una manera más genérica, pero esto simplemente lo hace funcionar de inmediato. Entonces, efectivamente, lo que hacemos aquí es que verificamos en función del archivo que existe en el paquete, pero también el archivo que existe en el binario de la aplicación. Y nos aseguramos de que sean el mismo recurso nombre. Y si no lo son, asumimos que es otro paquete que se va a utilizar. Y ahora que hemos hecho un code push, podemos volver. Ahora, lo que vamos a hacer para que esta actualización se active es que vamos a cerrar la aplicación, y luego en el próximo inicio de la aplicación cuando la abramos, lo primero que verás es que está de vuelta en donde solía estar, pero si esperamos un segundo, consultará. Y luego, una vez que sabe que ha habido una actualización, en realidad actualiza la aplicación. Entonces ahora dice, ¿cómo estás hoy, Mo? Vale, genial. Eso ha sido actualizado ahora. Y luego, si vamos a esta pantalla, puedes ver que ahora
9. Ecosistema Microfrontend y Empaquetado React Native
Viven en repositorios separados y podrían ser desarrollados por diferentes equipos. Webpack es el empaquetador de facto para microfrontends, pero Metro es el empaquetador de elección para React Native. Hay un trabajo en curso para hacer que Metro sea más compatible y adecuado para una amplia gama de usos. Las comunidades alrededor de Vite y Rollup han implementado sus propias versiones de federación de módulos, y es solo cuestión de tiempo antes de que llegue a Metro. La arquitectura única de React Native con la capa de JavaScript y la capa Nativa proporciona un enorme potencial para avances arquitectónicos.
obtuvo el vehículo desbloqueado. Entonces estos dos
modules han sido desplegados de forma independiente. Viven en repositorios separados. Esto está dentro de un repositorio llamado pantalla de tablero, y este está en otro repositorio llamado pantalla remota. Y están siendo desarrollados. En teoría, podrían ser desarrollados por diferentes equipos, y podrían ser publicados de forma independiente. Genial. Así que hemos echado un vistazo a cómo usar CodePush y
React Native para crear una aplicación muy básica, impulsada por microfrontend. Ahora, retrocedamos y echemos un vistazo general a donde se encuentra todo el microfrontend
ecosystem y donde se encuentra todo el empaquetado
React Native en este momento.
Webpack es el de facto
bundler para usar para microfrontends, y eso es porque Module Federation es una parte clave del
Webpack ecosystem. Y Module Federation realmente viene con todas las herramientas adecuadas como un plugin para que puedas construir microfrontends realmente efectivos en la web. Hay muchos recursos geniales sobre esto. Recomiendo encarecidamente ver algunas de las charlas de Luca Mesoleri, que trabaja en
AWS, sobre el uso de Module Federation y microfrontends en general. Creo que hay cosas geniales para aprender allí. Y es realmente donde se encuentra la madurez, especialmente en el sitio web.
Ahora, naturalmente, muchas personas también se han sentido atraídas por esto para móviles. Recientemente, ha habido un nuevo kit de herramientas basado en Webpack que te permite usar Webpack en lugar de Metro como tu bundler en una aplicación React Native. Y una de las razones principales para eso es ser capaz de usar Module Federation y poder construir microfrontends dentro de aplicaciones móviles. El desafío con esto es que Webpack no es un ciudadano de primera clase en el React Native ecosystem. En el estado actual, muchas partes diferentes de la community se están moviendo hacia Metro. En el pasado, si tenías una React Native para una aplicación web, sería que usarías Webpack para el sitio web y usarías Metro para el lado móvil. Hoy en día, si construyes una aplicación universal dentro del Expo ecosystem, se recomienda que uses Metro para la web también. Metro es realmente el bundler de elección para la React Native community, y la mayoría de las personas están invirtiendo mucho en Metro. Hay mucho buen trabajo que se está haciendo para hacer que Metro sea cada vez más compatible y más adecuado para una amplia gama de usos. En última instancia, estoy muy emocionado por un futuro en el que Metro pueda quizás soportar alguna forma de federación de módulos. Ahora, esto no está realmente muy lejos. Las comunidades alrededor de Vite y Rollup han implementado sus propias versiones de federación de módulos. Hay un muy próspero proyecto de código abierto dedicado a implementar la federación de módulos dentro de Vite que también es compatible con Rollup, de hecho. Así que hay mucho buen trabajo que se puede hacer y que ya ha sido hecho por otras comunidades alrededor de diferentes empaquetadores, y creo que es solo cuestión de tiempo antes de que un mecanismo como la federación de módulos llegue a Metro, y creo que es ahí donde React Native realmente brillará debido a la arquitectura única que tiene con la capa de JavaScript y la capa Nativa. Hay cantidades masivas de poder para tomar algunos de los avances arquitectónicos que han existido en el sitio web y llevarlos al móvil. Así que estoy muy emocionado por eso. Pero todavía hay algunos
10. Desafíos con Micro Frontends y Móviles
El concepto teórico de micro frontends no funciona bien con móviles debido a varios bloqueadores. El código nativo no puede ser impulsado por código, requiriendo un sistema bien pensado y una tubería de construcción para gestionar diferentes equipos introduciendo nuevo código nativo o dependencias. Las actualizaciones aún deben ser desplegadas a través de la tienda de aplicaciones para características que no están basadas en JavaScript.
desafíos. Y entonces vamos a hablar de por qué este tipo de concepto teórico de micro front test no funciona realmente con móviles. Todavía hay bastantes bloqueadores. En primer lugar, está el código nativo. Puedes impulsar cualquier cosa que esté en
JavaScript pero no puedes impulsar ningún nuevo código nativo. Y así, a medida que divides tu aplicación en diferentes micro front ends, necesitas pensar en un sistema bien pensado y una buena tubería de construcción y despliegue que permita efectivamente gestionar estos diferentes equipos a medida que empiezan a introducir nuevo código nativo o quizás cambien sus dependencias nativas e introduzcan nuevas dependencias nativas para asegurarte de que todavía estás desplegando actualizaciones a través de la tienda de aplicaciones con nuevos binarios de aplicaciones y las envías a tus usuarios cada vez que necesitas introducir características que no están basadas sólo en
JavaScript. El otro ángulo es que necesitas asegurarte de que todos estos diferentes equipos que están trabajando dentro del subconjunto de la gran aplicación están trabajando en un entorno muy similar. ¿Verdad? Realmente no puedes ser agnóstico tecnológicamente en el lado móvil porque muchas de estas dependencias necesitan ser igualadas a través de los tableros. Estas dependencias nativas, no puedes tener diferentes versiones de dependencias nativas en una única carcasa de aplicación. Todos necesitan estar usando una única versión de
React o cualquier otra biblioteca que pueda ser dependencias basadas en nativas. Así que la idea de agnosticismo tecnológico realmente no se aplica mucho al espacio móvil. Y entonces vas a necesitar asegurarte de que hay una coordinación entre los diferentes equipos para poder entregar micro front-ends en una única aplicación. Y por último, el enfoque que acabamos de ver con
Code estaba efectivamente agrupando dos paquetes
React nativos en una única aplicación y teniendo dos instancias de
React nativo funcionando en una única aplicación. Y entonces va a haber muchos recursos que vas a estar usando innecesariamente allí. No está optimizado todavía. No es una forma optimizada. No hay una forma optimizada para poder tomar los bits comunes que tu aplicación puede tener en una única carcasa y extraerlos y tenerlos accesibles por los diferentes paquetes. Tal como está, estás agrupando todo lo que se necesita para ejecutar dos vistas raíz separadas de
React nativo y dos instancias separadas del puente. Y eso puede naturalmente consumir muchos más recursos y mucho más espacio. Así que va a necesitar algunos avances allí antes de que creo que pueda ser sostenible y estar listo para la producción. Y finalmente, nos deja con la pregunta, bueno, ¿qué hacemos con los micro frontends para móviles? Y creo que aunque hay muchos bloqueadores para lograr verdaderos micro frontends en móviles, hay mucho que podemos aprender de los paradigmas arquitectónicos. Este año en la masterclass de
React Nativo EU, hubo una charla muy interesante sobre el diseño impulsado por características. Y se titula El Mejor Amigo de los Micro Frontends, y es el ejemplo de la aplicación Chase UK. Y te recomendaría mucho que la vieras. Yo creo que toma algunos de estos paradigmas y habla de cómo todavía puedes intentar escalar tus equipos y tomar los beneficios de velocidad y las tasas de entrega utilizando algunos de estos conceptos. Y creo que es una charla realmente genial. Así que siéntete libre de escanear el código QR para ver eso también. Pero finalmente, el aprendizaje que obtuve de mirar todo esto de manera holística es que cuando estás construyendo una aplicación a gran escala, necesitas ser impulsado por características y mirar la modularización de estas aplicaciones. Y me lleva de vuelta a la aplicación que estamos construyendo actualmente para nuestro servicio de streaming. Hemos intentado aislar estas en pequeñas características, en bits modularizados que pueden ser aislados y probados individualmente y desarrollados individualmente. Y finalmente, hemos visto realmente las recompensas de ello. Y creo que este es un concepto que se deriva de la idea de los micro front-ends, pero hemos podido aprovechar de manera pragmática y usar de una manera que es razonable y todavía nos da muchos de los beneficios que habríamos obtenido con una arquitectura de micro front-ends. Así que mi recomendación es, no necesariamente necesitas saltar a un micro front-ends y abrazarlo en toda su plena gloria. Tomando algunos de estos conceptos alrededor de la modularización, desglosando las cosas, tratando de dividirlas, y empaquetando y compartimentando... Con esa mentalidad, si la llevas a tu próxima aplicación, creo que hay muchas mejoras que puedes ver, y espero que estés entregando valor más rápido a tus usuarios y construyendo una aplicación en general mejor. Muchas gracias por escuchar. Siempre estoy aquí para charlar, así que si te gustaría ponerte en contacto conmigo, siéntete libre de escanear el código QR para Twitter o para LinkedIn, y espero veros a todos en persona en Londres.
