Microfrontends: Fragmentando el Monolito UI

1️⃣ Introducción

A medida que una aplicación frontend crece:

• El tiempo de build aumenta.
• Los conflictos entre equipos son más frecuentes.
• Un cambio pequeño puede afectar múltiples módulos.
• Los despliegues se vuelven riesgosos.

Un monolito frontend funciona bien al inicio, pero en productos que escalan termina convirtiéndose en un cuello de botella técnico y organizacional.

Esta guía explica cómo dividir una aplicación monolítica en microfrontends independientes utilizando Module Federation (Webpack 5).

---

2️⃣ ¿Qué son los Microfrontends?

Los microfrontends aplican los principios de microservicios al frontend:

• División por dominios de negocio.
• Equipos independientes por módulo.
• Despliegue autónomo.
• Versionado desacoplado.
• Evolución tecnológica progresiva.

Cada parte de la aplicación puede desarrollarse, desplegarse y escalarse sin depender completamente del resto.

---

3️⃣ ¿Qué es Module Federation?

Module Federation es una funcionalidad de Webpack 5 que permite:

• Compartir código en tiempo de ejecución.
• Cargar módulos remotos dinámicamente.
• Evitar duplicación de dependencias como react o react-dom.

En lugar de compilar todo en un solo bundle, cada aplicación puede exponer componentes que otros proyectos consumen dinámicamente.

---

4️⃣ Arquitectura Base

En una arquitectura típica existen dos roles:

🔹 Host (Shell / Contenedor)

Aplicación principal que consume microfrontends.

🔹 Remote

Aplicaciones independientes que exponen componentes.

Ejemplo estructural:

shell-app (Host)
│
├── auth-app (Remote)
├── dashboard-app (Remote)
└── profile-app (Remote)

Cada remote puede desplegarse en un servidor distinto.

---

5️⃣ Configuración del Remote (Microfrontend)

Archivo: webpack.config.js

const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
const deps = require("./package.json").dependencies;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "auth_module",
      filename: "remoteEntry.js",
      exposes: {
        "./LoginForm": "./src/components/LoginForm",
      },
      shared: {
        ...deps,
        react: { singleton: true, requiredVersion: deps.react },
        "react-dom": { singleton: true, requiredVersion: deps["react-dom"] },
      },
    }),
  ],
};

🔎 Explicación

• name: Identificador del microfrontend.
• filename: Archivo que expone los módulos.
• exposes: Componentes disponibles para otras apps.
• shared: Librerías compartidas para evitar duplicación y conflictos de versión.

---

6️⃣ Configuración del Host

new ModuleFederationPlugin({
  name: "shell",
  remotes: {
    auth_module: "auth_module@http://localhost:3001/remoteEntry.js",
  },
  shared: {
    react: { singleton: true },
    "react-dom": { singleton: true },
  },
});

Ahora puedes consumir el componente remoto dinámicamente:

const LoginForm = React.lazy(() => import("auth_module/LoginForm"));

---

7️⃣ Flujo de Ejecución

1. El Host se carga.
2. El Host solicita remoteEntry.js.
3. Webpack registra los módulos expuestos.
4. Cuando se importa el componente remoto, se descarga dinámicamente.
5. React lo renderiza mediante React.lazy y Suspense.

---

8️⃣ Buenas Prácticas

• Compartir siempre react y react-dom como singleton.
• Separar por dominio de negocio, no por tipo de componente.
• Definir contratos claros entre microfrontends.
• Usar Suspense para manejar estados de carga.
• Mantener CI/CD independiente por módulo.
• Versionar cada microfrontend de forma autónoma.

---

9️⃣ Ventajas

• Escalabilidad organizacional.
• Despliegues independientes.
• Reducción de conflictos entre equipos.
• Migraciones progresivas de tecnología.
• Mejor aislamiento de fallos.

---

🔟 Desventajas

• Mayor complejidad inicial.
• Debugging distribuido.
• Necesidad de gobernanza técnica.
• Riesgo de inconsistencias si no hay estándares claros.

---

1️⃣1️⃣ ¿Cuándo Usar Microfrontends?

Recomendado cuando:

• El equipo frontend supera 5–8 desarrolladores.
• Existen dominios de negocio bien definidos.
• Se necesita despliegue independiente.
• El producto tiene alto crecimiento proyectado.

No recomendado para:

• Proyectos pequeños.
• MVPs tempranos.
• Equipos de 1–2 personas.

---

Conclusión

Los microfrontends no son una tendencia pasajera, sino una estrategia arquitectónica para escalar aplicaciones y equipos.

Module Federation permite fragmentar el monolito UI sin perder cohesión, facilitando despliegues independientes y evolución tecnológica controlada.

La clave no es dividir por dividir, sino fragmentar estratégicamente por dominio de negocio.