El contrato es la pieza crítica en micro frontends con Module Federation
La verdadera dificultad no es la configuración del bundler, sino asegurar la compatibilidad entre el shell y los remotos mediante un contrato bien definido.
Los artículos sobre Module Federation suelen terminar en la configuración del plugin y los exposes. Lo que realmente determina el éxito es el contrato entre el shell y los remotos. En un caso concreto, un portal de eventos gubernamentales se dividió en equipos, cada uno entregando su parte como un build independiente. El objetivo era que cada equipo pudiera desplegar sin coordinar a todo el grupo. Con la federación, el shell carga los módulos en tiempo de ejecución, donde desaparecen las garantías de build. Una incompatibilidad ya no genera error de compilación, sino un panel en blanco o un fallo inesperado.
Para evitar eso, se definió un contrato explícito y versionado. Cada remoto declara qué expone, qué props espera, la forma de los eventos y el rango de dependencias compartidas con las que se construyó. El shell valida ese rango antes de montar cualquier componente. Si la versión está fuera de rango, el shell rechaza el remoto y muestra un fallback predefinido.
Los beneficios son claros:
- Fallos detectados a la carga, con mensaje de remoto y rango esperado.
- Despliegues independientes, sin tren de release ni cola.
- Dependencias compartidas controladas; React y el sistema de diseño se declaran con rangos explícitos, eliminando la incertidumbre.
- Reducción del ciclo de release en torno al 40 %, principalmente por eliminar esperas.
Recomendaciones:
- Escribir el contrato antes de tocar la configuración del build.
- Definir el comportamiento en caso de fallo de carga (fallback, error boundary, feature flag). El valor por defecto suele ser un rectángulo en blanco.
- Mantener la lista de dependencias compartidas corta; cada dependencia es un acoplamiento que debe versionarse.
- Dividir por propiedad del equipo, no por página, para lograr despliegues independientes.
Cuando no hay un problema organizacional, la complejidad de micro frontends no justifica su adopción. En esos casos, la configuración del bundler y la división de código tradicionales son suficientes.
Para profundizar en el caso práctico de la plataforma de eventos de Qatar, consulta la documentación del proyecto.
