Microfrontends: equipos que despliegan solos

Es tentador confundir Module Federation con los microfrontends, pero son cosas de distinto orden. Module Federation es una técnica de integración en runtime; los microfrontends son una arquitectura, y su motivación no es técnica sino organizativa: permitir que muchos equipos posean cada uno un trozo de la interfaz y lo desplieguen a su propio ritmo, sin sincronizar una release única y monolítica. Cada microfrontend se comporta como un paquete versionado, publicado en una URL estable, y una app shell los compone en la pantalla del usuario.

De una técnica a una arquitectura

Un microfrontend es la extensión al frontend de la idea de microservicio: partir una aplicación grande en piezas que equipos distintos desarrollan, prueban y despliegan por separado. Module Federation es una de las formas de implementarlo, pero no la única: hay microfrontends montados con iframes, con Web Components, con import maps, con composición en el borde. La técnica es intercambiable; la arquitectura es la decisión de fondo.

Y esa decisión es, ante todo, organizativa. La ley de Conway dice que la arquitectura de un sistema tiende a copiar la estructura de comunicación de la organización que lo construye. Los microfrontends son la aplicación deliberada de ese principio: si tienes ocho equipos autónomos, en lugar de forzarlos a compartir un monolito donde se pisan en cada release, les das a cada uno una frontera de despliegue propia que refleje su autonomía real.

Despliegue independiente: el verdadero objetivo

Todo lo demás en los microfrontends es medio; el fin es el despliegue independiente. Un equipo que posee el microfrontend de búsqueda debe poder arreglar un bug, construir su artefacto y publicarlo en producción sin recompilar ni redeplegar el resto de la aplicación, y sin esperar a la ventana de release de nadie. Ese es el valor que justifica toda la complejidad que veremos en la próxima lección.

Aquí es donde encaja Module Federation: al integrar en runtime, permite que cada equipo despliegue su remote en su URL cuando quiera, y que la app shell recoja la versión nueva en la siguiente carga. Sin integración en runtime, la independencia se evapora: si componer requiere recompilar el contenedor, has vuelto al monolito con pasos extra.

flowchart TD
Shell[app shell orquesta la pantalla] --> A[mfe busqueda equipo A]
Shell --> B[mfe catalogo equipo B]
Shell --> C[mfe carrito equipo C]
A -->|despliega solo| DA[pipeline A]
B -->|despliega solo| DB[pipeline B]
C -->|despliega solo| DC[pipeline C]
style Shell fill:#cba6f7,color:#11111b
style A fill:#89b4fa,color:#11111b
style B fill:#a6e3a1,color:#11111b
style C fill:#f9e2af,color:#11111b

Cada microfrontend como paquete versionado

Para que un equipo consuma el trabajo de otro sin acoplarse a su código fuente, cada microfrontend se comporta como un paquete versionado: publica un artefacto —su manifiesto y sus chunks— en una URL estable, con un contrato claro de qué expone. La app shell no conoce el código del microfrontend; conoce su URL y su API pública, igual que un consumidor de una librería conoce su interfaz y no sus entrañas.

El versionado de esa URL es una decisión de diseño con consecuencias. Apuntar a una URL de última versión da despliegue instantáneo pero ninguna red de seguridad: el nuevo remote llega a todos a la vez. Versionar la URL —incluir un número o un hash— permite despliegues graduales, rollbacks y que la shell fije qué versión de cada microfrontend compone, a cambio de un paso de promoción explícito.

// La shell registra cada microfrontend por su URL versionada.
registerRemotes([
  { name: "busqueda", entry: "https://cdn.example.com/busqueda/v4/mf-manifest.json" },
  { name: "catalogo", entry: "https://cdn.example.com/catalogo/v9/mf-manifest.json" },
  { name: "carrito", entry: "https://cdn.example.com/carrito/v2/mf-manifest.json" },
]);

Las estrategias de composición

Las tres tarjetas anteriores marcan un eje: cuándo se ensamblan las piezas. En build, integras al compilar la shell —tienes tipos y verificación, pero pierdes la independencia, porque cada cambio de un microfrontend recompila el contenedor—. En el servidor, ensamblas HTML de varios orígenes en el borde, con buen tiempo de primer pintado. En runtime, integras en el navegador, que es lo que da la independencia plena a costa de la fragilidad de la red. Module Federation vive en esta tercera casilla, y por eso arrastra tanto sus virtudes como sus peligros.

El panorama de 2026 ofrece varias encarnaciones de la idea. single-spa orquesta microfrontends de frameworks distintos bajo un router común; Piral añade un modelo de portal con pilets; Native Federation implementa la composición en runtime con import maps y ESM estándar, sin atarse a un bundler; y Module Federation 2.0 sobre Rspack es la vía más integrada cuando todos los equipos comparten toolchain. Todas resuelven el mismo problema organizativo con distintos compromisos técnicos.