Micro Frontends en serio: cuándo convienen y cómo implementarlos

TL;DR
Úsalos cuando tengas múltiples squads y dominios claros. Define un design system compartido, segmenta routing, controla performance (duplicados) y traza límites de ownership.

¿Qué son y por qué?

Aplicar microservicios al frontend para escalar equipos y dominios.

Ventajas

• Autonomía de equipos, despliegue independiente, escalabilidad

Desventajas

• Complejidad, duplicación, performance y consistencia visual

Module Federation (webpack)

Host

const { ModuleFederationPlugin } = require('webpack').container
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        userMfe: 'userMfe@http://localhost:3001/remoteEntry.js',
        productMfe: 'productMfe@http://localhost:3002/remoteEntry.js',
      },
      shared: { react: { singleton: true }, 'react-dom': { singleton: true } }
    })
  ]
}

Remote

new ModuleFederationPlugin({
  name: 'userMfe',
  filename: 'remoteEntry.js',
  exposes: { './UserApp': './src/UserApp' },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } }
})

Comunicación

• Props/callbacks
• Custom events
• Estado compartido (p. ej. Zustand) sólo si es imprescindible

Deployment

• Build-time vs Run-time vs Server-side (elige según SEO/latencia)

Buenas prácticas

• Design system compartido versionado
• Routing coordinado
• Error boundaries + observabilidad por MFE
• Límite de tamaño por MFE y auditoría de duplicados

Cuándo usar / evitar

SÍ: +10 devs, dominios claros, releases independientes
NO: equipo pequeño, producto early-stage

Alternativas

Single-SPA, Bit (componentes), Nx (monorepo)

Conclusión

Potentes en organizaciones grandes; evita el sobre-diseño en productos jóvenes.