Versión estable de MF 2.0: equilibrio entre productividad del desarrollador y rendimiento extremo

Hace un año liberamos como código abierto Module Federation 2.0 (MF 2.0) y, desde entonces, hemos recibido una gran cantidad de comentarios y sugerencias valiosas de la comunidad. Creemos que una solución de micro-frontends madura no solo debe mejorar la eficiencia del desarrollo colaborativo, sino también ofrecer un motor central que permita un rendimiento extremo. Con esto en mente, hemos dedicado el último año a pulir a fondo MF 2.0 y ampliar sus capacidades.

Hoy nos complace anunciar que MF 2.0 ya es oficialmente estable. La versión estable ofrece potentes optimizaciones de rendimiento, cubre una gama más amplia de escenarios de despliegue y mejora significativamente la experiencia de desarrollo.

Sistema de optimización de rendimiento de extremo a extremo

MF 2.0 reestructura de forma sistemática el pipeline de rendimiento de las aplicaciones micro-frontend en cuatro etapas: build, carga de recursos, renderizado y obtención de datos.

Estas capacidades no existen de forma aislada; trabajan juntas para formar un sistema de optimización de rendimiento de extremo a extremo diseñado para escenarios de module federation.

Todas las capacidades admiten una adopción incremental. Puedes habilitarlas de forma gradual según las necesites, sin reescribir de golpe tu arquitectura actual y sin comprometer la estabilidad de los sistemas existentes.

Tree shaking para dependencias shared

Las dependencias shared tradicionales evitan la carga duplicada, pero para garantizar su completitud, las bibliotecas compartidas suelen empaquetarse y exponerse como paquetes completos. Aunque solo uses una pequeña parte, sigues teniendo que cargar toda la biblioteca, lo que hace que el tamaño de los bundles crezca continuamente.

En MF 2.0, este problema está resuelto:

Las dependencias shared ahora admiten tree shaking.

Con solo habilitar treeShaking, MF puede podar bajo demanda las dependencias shared sin sacrificar la naturaleza dinámica de module federation. Conserva únicamente los módulos que realmente es probable que se usen, lo que reduce significativamente el tamaño de los bundles shared sin perder compatibilidad con los proyectos existentes.

MF 2.0 ofrece dos modos para adaptarse a distintos escenarios:

  • runtime-infer: sin dependencias externas y listo para usar. En runtime, MF intenta primero reutilizar los bundles shared con tree shaking que ya están cargados; si sus capacidades no son suficientes, recurre automáticamente a cargar la dependencia completa para garantizar la funcionalidad. Puedes mejorar la eficacia de la reutilización con usedExports.

  • server-calc: un modo en el que el servidor o el sistema de CI analiza el uso de dependencias en varias aplicaciones y produce un resultado de poda de shared óptimo a nivel global, adecuado para sistemas grandes.

También se incluye un panel de análisis visual que facilita ver cómo se usan las dependencias shared y cuánto tamaño de bundle ahorran.

En una biblioteca de componentes grande como Ant Design, cuando una aplicación solo usa los componentes Badge, Button y List, el tamaño del bundle shared es de unos 1404.2 KB sin tree shaking de dependencias shared. Tras habilitar el tree shaking, el tamaño cargado real baja a 344.0 KB, lo que reduce el código innecesario en aproximadamente un 75.5%.

Configuración Resultado del análisis

Renderizado del lado del servidor (SSR)

SSR genera el HTML completo en el servidor y lo devuelve directamente al navegador, de modo que las páginas pueden renderizarse sin esperar a la hidratación en el cliente. Esto mejora de forma drástica el rendimiento de la primera pantalla y el SEO. Para aplicaciones web medianas y grandes, SSR se ha convertido prácticamente en una capacidad estándar.

Sin embargo, en las arquitecturas de micro-frontends, SSR ha sido históricamente difícil de implementar. Las primeras versiones de MF no cubrían esta capacidad, lo que obligaba a los desarrolladores a elegir entre flexibilidad arquitectónica y ventajas de rendimiento.

En MF 2.0, este compromiso desaparece.

Puedes usar MF SSR directamente dentro de Modern.js, lo que también aporta capacidades de SSR de alto rendimiento a las aplicaciones micro-frontend.

Precarga de datos isomórfica

MF 2.0 introduce una nueva solución isomórfica de obtención de datos que admite escenarios tanto de SSR como de CSR. Ofrece las APIs integradas prefetch y cache para unificar la precarga de datos y la gestión de la caché, lo que garantiza un rendimiento estable y predecible en los distintos modos de renderizado.

Gracias a la precarga y la caché, las páginas pueden preparar los datos críticos antes de renderizar, evitando solicitudes repetidas y cargas en cascada, lo que mejora significativamente tanto la carga inicial como la capacidad de respuesta interactiva.

Capacidades impulsadas por Rust

En proyectos grandes, la generación del manifest suele convertirse en un cuello de botella de rendimiento durante la fase de build. MF 2.0 traslada esta capacidad central a una implementación en Rust, aprovechando el alto rendimiento y la seguridad de memoria de Rust para reducir sustancialmente el tiempo necesario para generar los manifests.

Al mismo tiempo, AsyncStartUp también se ha reescrito en Rust. Ya no necesitas configurar entry points asíncronos para obtener capacidades equivalentes, y los riesgos de rendimiento de la primera pantalla asociados se eliminan de forma efectiva, lo que hace que la ruta de arranque de la aplicación sea más sencilla, estable y eficiente.

Un sistema de depuración más potente

MF 2.0 construye un sistema de depuración completo en torno a la observabilidad y la depurabilidad. Hace que las dependencias shared, las relaciones entre módulos y los posibles efectos secundarios sean visibles, rastreables y detectables de antemano, lo que reduce enormemente la incertidumbre al desarrollar e integrar aplicaciones dinámicas.

Escáner de efectos secundarios

Antes de consumir un módulo remoto, los equipos suelen necesitar evaluar si contamina variables globales, registra listeners de eventos o afecta al alcance de los estilos: incertidumbres que aumentan significativamente el costo de adoptar micro-frontends.

MF 2.0 ofrece un Side Effect Scanner (escáner de efectos secundarios) que analiza estáticamente los resultados del build e identifica los siguientes efectos secundarios:

  • Variables globales
  • Listeners de eventos
  • Alcance de impacto de los selectores CSS

La herramienta CLI que lo acompaña puede realizar los análisis automáticamente y mostrar los resultados, lo que permite a los consumers conocer los riesgos antes de la integración y, por tanto, reducir significativamente el costo de incorporar módulos federados.

Extensión de Chrome para visualizar dependencias

Hemos actualizado por completo la extensión de Chrome existente con una nueva interfaz y capacidades de depuración más potentes, haciendo que el estado en runtime de module federation sea visible, consultable y verificable.

  • Sincronización inteligente de la barra lateral El panel sigue automáticamente a la página actual sin necesidad de refrescar ni volver a conectar manualmente, lo que ofrece una experiencia de depuración más fluida.

  • Visualización de dependencias shared El nuevo panel Shared muestra con claridad la carga de dependencias shared en la página actual, por ejemplo:

    • Si React se comparte correctamente
    • Qué versión shared se está usando realmente
    • Si tu estrategia de compartición funciona como esperas Visualización de dependencias shared
  • Navegación rápida por el grafo de dependencias Puedes buscar cualquier módulo en el grafo de dependencias y ver sus relaciones ascendentes y descendentes en una jerarquía clara, lo que facilita razonar sobre dependencias complejas.

Grafo de dependencias

  • Modo de recorte de datos Cuando hay muchos módulos, puedes habilitar el modo de recorte para reducir el tamaño de los datos del proxy y evitar fallos de inyección provocados por los límites de localStorage. Los datos recortados solo afectan al análisis de precarga, no al comportamiento real, por lo que es seguro habilitarlo.

Un ecosistema más rico

MF ahora es compatible con los principales bundlers, frameworks de aplicación y stacks de UI, y puede ejecutarse de forma fiable en distintos ecosistemas técnicos, lo que ayuda a los equipos a introducir module federation sin cambiar sus elecciones tecnológicas actuales.

  • Bundler: Webpack / Rspack / Rollup / Rolldown

  • Herramienta de build: Rsbuild / Vite / Metro

  • Framework/herramienta: Modern.js / Next.js / Rspress / Rslib / Storybook

  • Biblioteca de UI: React / Vue / React Native

Ecosistema de MF 2.0

Además, MF 2.0 extiende las capacidades de module federation a más escenarios críticos de desarrollo y entrega:

Node.js

Ahora module federation puede usarse directamente en el runtime de Node.js, de modo que los módulos remotos pueden consumirse no solo desde el navegador, sino también desde SSR, BFF y las capas de servicio de Node, lo que permite un modelo de entrega unificado de módulos entre frontend y backend.

División de documentación en Rspress

En Rspress, MF admite dividir y cargar módulos remotos por documento o por ruta, lo que permite descomponer y publicar de forma independiente mediante module federation sitios de documentación grandes, algo ideal para plataformas de documentación y conocimiento con varios equipos.

Rstest

Dentro del sistema de testing de Rstest, module federation puede cargar módulos remotos tal como ocurre en un runtime real, lo que permite que las aplicaciones micro-frontend y MF realicen pruebas de integración y pruebas de extremo a extremo que reflejan fielmente producción, evitando la brecha entre las pruebas y el comportamiento real en runtime.

Cambios

Cambios de versión (cambios menores)

Priorizamos la estabilidad y la compatibilidad, por lo que esta actualización no contiene cambios incompatibles y solo introduce algunas actualizaciones menores. Los cambios clave son:

Cambios menores

  • El valor por defecto de library.type cambia de var a global.
  • runtimePlugins ahora admite parámetros de configuración.

¿Qué viene ahora?

React Server Components

Los React Server Components (RSC) suponen un avance revolucionario en el ecosistema de React. En comparación con MF x SSR, la combinación de MF x RSC puede ofrecer un rendimiento aún mejor (con bundles mucho más pequeños) y un manejo de datos más seguro. Ya hemos validado este enfoque en demos básicas y ofreceremos un soporte y una integración más sólidos en Modern.js.

Diseño pensado para la IA

Estamos enriqueciendo gradualmente MF con la información contextual y los metadatos que la IA necesita para usar componentes y módulos, incluidos los límites de capacidad, las restricciones de uso, los entornos de ejecución y las relaciones de dependencia. También planeamos introducir mecanismos cuantitativos de puntuación y confianza para que la IA pueda entender, evaluar y seleccionar los activos de componentes.