Saltar al contenido

Lección 16 de 16 · Lectura y práctica

Probar la Escalabilidad y Rendimiento del Proyecto

Tipo de lección: QuizConcepto claveProbar la escalabilidad y rendimiento en micro-frontends con Module Federation significa evaluar cómo el sistema se comporta bajo carga creciente y cómo optimizar la entrega de módulos.

Del concepto a la práctica

Taller de esta lección

Una prueba de rendimiento útil separa tiempo de red, evaluación del módulo y renderizado. Si solo se mide el tiempo total de la pantalla, no se sabe si el problema está en una URL lenta, un bundle grande o trabajo excesivo del componente.

Ejemplo resuelto

En un modelo simplificado sin otros costos, metrics/remoteEntry.js tarda 120 ms, un fragmento tarda 80 ms y el renderizado tarda 40 ms. El tiempo secuencial observado es 120 + 80 + 40 = 240 ms. Si agregas un segundo fragmento de 80 ms, ambos secuenciales darían 320 ms totales; en paralelo, el tramo de red es 120 + max(80,80) = 200 ms y el total vuelve a 240 ms con renderizado. Compara este cálculo ideal con las mediciones reales de evaluación, red y caché.

Pruébalo

  1. Registra duración y nombre de cada recurso remoto.

  2. Mide por separado la evaluación y el renderizado si tu instrumentación lo permite.

  3. Repite con uno, dos y tres remotos bajo la misma red simulada.

  4. Compara medianas de cinco ejecuciones, sin mezclar caché fría y caliente. Error frecuente: sumar duraciones paralelas como si fueran siempre secuenciales. Corrección: representar dependencias y usar el máximo dentro de cada grupo paralelo.

Comprueba tu resultado

Con tres recursos paralelos de 120, 80 y 50 ms, seguidos de 40 ms de renderizado, el tiempo calculado es 120 + 40 = 160 ms. Si se obtiene 290 ms, se sumaron tramos paralelos incorrectamente. Anota además si la caché estaba fría o caliente.

Navegador, API y base de datos conectados por solicitudes, consultas y respuestas en sentidos opuestos.
CursaloMapa de práctica
Del navegador a los datos

El navegador envía una solicitud a la API. El servidor valida la operación y consulta los datos; después devuelve una respuesta que el navegador puede mostrar. La base de datos se comunica con el servidor y no directamente con el navegador.

Ver la infografía en tamaño completo ↗

Tipo de lección: Quiz

Concepto clave

Probar la escalabilidad y rendimiento en micro-frontends con Module Federation significa evaluar cómo el sistema se comporta bajo carga creciente y cómo optimizar la entrega de módulos distribuidos. Imagina una ciudad donde cada barrio (micro-frontend) tiene su propia administración, pero todos comparten servicios públicos (dependencias compartidas). La escalabilidad prueba si la ciudad puede crecer sin colapsar, mientras el rendimiento mide cuánto tardan los residentes en moverse entre barrios.

En arquitecturas distribuidas, la escalabilidad no es solo añadir más servidores, sino garantizar que la federación de módulos mantenga tiempos de carga predecibles cuando decenas de equipos despliegan cambios simultáneos. El rendimiento se enfoca en métricas como First Contentful Paint (FCP) y Largest Contentful Paint (LCP), que en micro-frontends dependen de la eficiencia de carga remota y caching de módulos.

Cómo funciona en la práctica

Para probar escalabilidad, simula escenarios donde múltiples equipos despliegan versiones nuevas de sus micro-frontends concurrentemente. Sigue estos pasos:

  1. Configura un entorno de staging con balanceadores de carga que sirvan los contenedores de cada micro-frontend.
  2. Usa herramientas como k6 o Artillery para generar tráfico simulado que acceda a rutas que cargan combinaciones aleatorias de módulos federados.
  3. Monitorea métricas clave: latencia de descarga de módulos, tasa de errores en federación, y uso de memoria del navegador.
  4. Incrementa gradualmente el número de solicitudes concurrentes hasta identificar cuellos de botella, como límites de conexiones HTTP o serialización lenta de módulos.

Para rendimiento, implementa code splitting dinámico y pre-caching de módulos frecuentes. Por ejemplo, si un módulo de "checkout" se usa en el 80% de las sesiones, precárgalo después del shell principal.

Codigo en accion

Antes: Carga perezosa básica sin optimización de caching.

// webpack.config.js del host
const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "host",
      remotes: {
        mf_checkout: "checkout@https://cdn.example.com/remoteEntry.js",
        mf_dashboard: "dashboard@https://cdn.example.com/dashboard/remoteEntry.js"
      },
      shared: ["react", "react-dom"]
    })
  ]
};

// Carga en componente
const CheckoutModule = React.lazy(() => import("mf_checkout/CheckoutPage"));

Después: Implementación con pre-fetching y métricas de rendimiento.

// webpack.config.js optimizado
const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "host",
      remotes: {
        mf_checkout: {
          external: "Promise.resolve(window.checkoutModule)",
          shareScope: "default"
        }
      },
      shared: {
        react: { singleton: true, eager: true },
        "react-dom": { singleton: true, eager: true }
      }
    })
  ]
};

// Pre-fetching estratégico
if (pathname === "/products") {
  import("mf_checkout/CheckoutPage").then(module => {
    window.checkoutModule = module;
    console.log("Checkout module pre-cached");
  });
}

// Medición de LCP
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.name === "mf_checkout") {
      console.log(`Module load time: ${entry.duration}ms`);
    }
  }
});
observer.observe({ type: "resource", buffered: true });

Errores comunes

  • No limitar el tamaño de bundles compartidos: Compartir librerías completas como lodash puede inflar el bundle inicial. Usa exposes selectivos y configura shared con versiones estrictas.
  • Ignorar la latencia de red en remotes: Asumir que los módulos remotos cargan instantáneamente lleva a timeouts. Implementa retries con exponential backoff y fallbacks visuales.
  • Sobrecargar el host con muchos remotes: Federar más de 10-15 módulos puede degradar el rendimiento. Agrupa módulos por dominio de negocio y usa lazy loading agresivo.
  • No monitorear el consumo de memoria: Cada micro-frontend aislado puede retener memoria. Usa herramientas como Chrome DevTools para detectar leaks y forzar garbage collection en transiciones.
  • Desplegar sin pruebas de carga cruzada: Actualizar un módulo sin probar su impacto en otros causa errores en cascada. Automatiza pruebas de integración con herramientas como Cypress que simulan interacciones entre módulos.

Checklist de dominio

  • ¿Has configurado métricas de rendimiento reales (RUM) para medir FCP y LCP por módulo federado?
  • ¿Implementaste estrategias de caching para módulos remotos (ej. Service Workers o CDN con invalidación)?
  • ¿Probaste el sistema con al menos 50 solicitudes concurrentes simulando múltiples equipos desplegando?
  • ¿Optimizaste las dependencias compartidas para evitar duplicación y conflictos de versiones?
  • ¿Diseñaste un plan de rollback rápido para módulos que degraden el rendimiento?
  • ¿Documentaste los acuerdos de interfaz entre módulos para prevenir breaking changes?
  • ¿Automatizaste las pruebas de carga en tu pipeline de CI/CD?

Simulación de Escalabilidad en un Ecosistema de Micro-frontends

En este ejercicio, crearás un entorno de prueba para evaluar cómo se comporta una arquitectura de micro-frontends bajo carga creciente. Sigue estos pasos:

  1. Configura dos micro-frontends remotos simples (ej. un componente de "ProductList" y otro de "UserProfile") usando Module Federation, cada uno en su propio repositorio o puerto.
  2. Crea un host que consuma ambos remotes dinámicamente basado en parámetros de URL.
  3. Usa k6 para escribir un script que simule 100 usuarios concurrentes accediendo a rutas aleatorias que cargan combinaciones de los módulos (ej. 50% carga solo ProductList, 30% ambos, 20% solo UserProfile).
  4. Ejecuta la prueba incrementando los usuarios a 200 y 300, monitoreando métricas como: tiempo de carga promedio de módulos, tasa de éxito de federación, y uso de CPU/memoria en el servidor.
  5. Identifica cuellos de botella y propone optimizaciones, como implementar pre-fetching para el módulo más usado o ajustar configuraciones de shared en webpack.

Entrega un reporte con gráficos de métricas y recomendaciones específicas basadas en tus hallazgos.

Pistas
  • Usa la opción 'shared: { eager: true }' para dependencias críticas y reduce round-trips.
  • En k6, configura etapas (stages) para incrementar la carga gradualmente y observar puntos de quiebre.
  • Monitorea la consola del navegador durante las pruebas para detectar errores de carga de módulos en tiempo real.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Sigue con Arquitectura de Micro-frontends con Module Federation de Webpack

Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.

Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.

01 / ELEGIR UNA RUTA

El próximo paso

Aprende IA mientras construyes algo que sí necesitas.

Empieza por el curso inicial o explora el catálogo para encontrar una práctica alineada con tu trabajo.