Los trade-offs: acoplamiento y monolito modular

Este nivel cierra con la lección más importante y la que más se omite: la federación se paga. Compartir dependencias, que resolvía la duplicación, reintroduce por la puerta de atrás el acoplamiento de versiones que los microfrontends prometían abolir. Los fallos dejan de detectarse en el build y aparecen en runtime, cruzando fronteras de despliegue que vuelven la depuración distribuida y difícil. Y muy a menudo, la arquitectura correcta no es federar, sino un monolito modular con fronteras internas bien impuestas.

El acoplamiento de versiones que nadie ve

La promesa de los microfrontends es la independencia: cada equipo despliega a su ritmo. La letra pequeña es shared. En el instante en que host y remotes comparten React como singleton, quedan atados a un rango de versiones mutuamente compatible. Ningún equipo puede saltar por su cuenta a la próxima major del framework: hacerlo rompería la única instancia que todos comparten. La independencia de despliegue convive, así, con una dependencia de versión que no aparece en ningún diagrama.

Es un acoplamiento especialmente traicionero porque es invisible hasta que muerde. Todo funciona mientras las versiones encajan; el día que un equipo necesita una major nueva e incompatible, descubre que su despliegue supuestamente autónomo requiere una migración coordinada de todos los demás. El acoplamiento estaba ahí desde el principio, latente en el contrato de shared, esperando la actualización que lo hiciera visible.

Depuración distribuida

En una aplicación única, un error tiene un stack trace que apunta a una línea de un build que controlas. En una federada, un error puede nacer en un remote construido por otro equipo, con otro pipeline, otros sourcemaps y otro calendario de despliegue, y manifestarse dentro del árbol del host. El rastro cruza una frontera de despliegue, y con ella se pierde buena parte del contexto: no siempre tienes los sourcemaps del remote, ni sabes qué versión estaba desplegada cuando el usuario falló.

A esto se suma un modo de fallo nuevo: un remote caído o incompatible no rompe un build, rompe una pantalla en producción. Una URL que devuelve 404, un manifiesto corrupto, una versión que dejó de negociar con el ámbito compartido: nada de esto existía en el monolito, donde lo que se desplegaba junto se compilaba junto. La federación te obliga a programar defensivamente contra la ausencia o el fallo de piezas que no controlas.

import { loadRemote, registerPlugins } from "@module-federation/runtime";

// Un plugin de runtime intercepta el fallo de un remote y degrada con gracia.
registerPlugins([
  {
    name: "fallback",
    errorLoadRemote({ id, error }) {
      reportar(id, error);
      return { default: () => renderMensajeDeGracia() };
    },
  },
]);

const modulo = await loadRemote("catalogo/Panel");

flowchart TD
U[usuario ve un error] --> Q{el fallo nacio en el host o en un remote}
Q -->|host| H[stack y sourcemaps propios]
Q -->|remote| R[otro build, otros sourcemaps, otra version]
R --> N[hace falta telemetria que cruce la frontera]
style U fill:#f38ba8,color:#11111b
style H fill:#a6e3a1,color:#11111b
style R fill:#fab387,color:#11111b
style N fill:#f9e2af,color:#11111b

Cuándo un monolito modular gana

Aquí está la conclusión que casi nadie pone por escrito: para la mayoría de los productos, un monolito modular es mejor que una federación. Un monolito modular es una sola aplicación, un solo despliegue, pero con fronteras internas rigurosas: módulos o paquetes de un workspace con límites que se imponen por herramienta —reglas de linter que prohíben importar a través de fronteras, referencias de proyecto de TypeScript, el grafo de un monorepo— en vez de por red.

Te da casi toda la modularidad de los microfrontends —código dividido por dominio, propiedad clara, fronteras explícitas— sin ninguno de sus impuestos de runtime: la integración vuelve a ocurrir en el build, así que el compilador verifica los contratos, no hay negociación de versiones que gestionar, no hay remotes que puedan caerse, y el stack trace vuelve a ser uno solo. Pierdes exactamente una cosa: el despliegue independiente. Si no lo necesitas de verdad, estás pagando toda la complejidad de la federación por un beneficio que no usas.