Estrategias Reales para la Migración de Frontends Complejos

El Fin del "Big Bang"

Todo dev senior ha estado en esta reunión. El legado ha acumulado una deuda técnica impagable, el tiempo de build toma minutos dolorosos, cada nueva feature rompe dos antiguas e, inevitablemente, alguien sugiere la frase maldita: "Vamos a parar todo y reescribir desde cero".

La intención es comprensible, pero en aplicaciones B2B a gran escala, el enfoque "Big Bang" —reconstruir todo en una branch paralela y cambiar el interruptor de una sola vez— es el camino más rápido para incumplir plazos, perder reglas de negocio implícitas y causar un caos absoluto en producción.

Si estás liderando la transición de un ecosistema complejo —digamos, migrando toda la interfaz y arquitectura de un sistema "GA2" a una versión "GA3"—, la refactorización necesita ocurrir con el avión en pleno vuelo. A continuación, detallo el verdadero camino para orquestar esto con Angular o React, enfocándome en los casos límite, fugas de estado y fallas silenciosas que suelen derribar el sistema en medio de la migración.

1. El Patrón Strangler Fig y la Trampa de las Dependencias

La estrategia arquitectónica más robusta hoy en día es el patrón Strangler Fig (Higuera Estranguladora). Construyes una aplicación "Shell" (el contenedor principal) que envuelve el sistema heredado y, usando Micro-frontends con Module Federation, delegas las rutas: lo que es nuevo carga la remote app GA3, lo que es antiguo carga el legado GA2.

⚠️ El Escenario de Falla: Conflicto de Singletons y la Pantalla Blanca de la Muerte

El error más común al federar módulos es subestimar el conflicto de versiones de bibliotecas base. El Shell puede estar en React 18, pero el legado atrapado en React 16. En Angular, los conflictos de versión de RxJS o del propio core entre el Shell y el remote son fatales.

Cómo se rompe el sistema: El usuario abre un modal en el módulo heredado. El Webpack del Shell intenta resolver el react-dom o el Zone.js compartido, encuentra una incompatibilidad de referencia en la memoria y lanza un error fatal. ¿El resultado? Una pantalla completamente blanca y una consola sangrando errores.

La Solución: Configuración paranoica de las shared dependencies en el webpack.config.js.

// webpack.config.js del Shell App
shared: {
  react: { 
    singleton: true, 
    requiredVersion: deps.react,
    strictVersion: true // Falla el build si la versión no coincide, evitando errores en runtime
  },
  "react-dom": { 
    singleton: true, 
    requiredVersion: deps["react-dom"] 
  }
}

2. La Fuga de Contexto en Entornos Multi-tenant

En plataformas SaaS, el usuario opera dentro de los límites de un tenant (empresa) específico. La aplicación Shell debe actuar como la Single Source of Truth (Única Fuente de Verdad) de este contexto.

⚠️ El Escenario de Falla: Race Conditions y la Pesadilla del Token

La desincronización entre la carcasa de la aplicación y los micro-frontends genera anomalías graves.

Cómo se rompe el sistema: El usuario está en una pantalla antigua (GA2) y cambia la empresa activa en el menú superior. A continuación, hace clic en un acceso directo a un panel ya migrado (GA3). El nuevo componente se monta antes de que el evento de "cambio de tenant" termine de propagarse. El nuevo panel dispara llamadas HTTP usando el Header o el Token del tenant anterior. El peor escenario no es un 401 Unauthorized; es que la API acepte la petición y renderice datos financieros de la empresa "A" en el panel de la empresa "B".

La Solución Técnica: En Angular 17+, la adopción de Signals a nivel del Shell resuelve esto con elegancia y sincronía, reemplazando la complejidad de los BehaviorSubjects.

// Shell App: tenant.service.ts
@Injectable({ providedIn: 'root' })
export class TenantContextService {
  public readonly activeTenantId = signal<string | null>(null);

  updateTenant(newId: string) {
    this.activeTenantId.set(newId);
  }
}

3. El Conflicto Sangriento de Design Systems (Elements/CSS)

Cuando juntas dos generaciones de código en la misma ventana del navegador, el CSS y los elementos globales son el primer punto de falla.

⚠️ El Escenario de Falla: CSS Bleeding y Sobrescritura de Elements

El sistema heredado GA2 usa un CSS global acoplado (ej: .btn, table tr td). La nueva interfaz GA3 fue construida con Tailwind o un Design System moderno (MUI, Angular Material).

Cómo se rompe el sistema: El CSS antiguo se inyecta en el <head>. Al navegar a una nueva ruta, el diseño moderno hereda propiedades del legado. Si usas Angular Elements para encapsular componentes, puedes sufrir porque los estilos globales intentan filtrarse hacia el Shadow DOM, o por conflictos de bibliotecas que intentan registrar selectores duplicados en el customElements del navegador.

La Solución:

1. Shadow DOM: Cambia la ViewEncapsulation de tus componentes críticos a ShadowDom. Esto crea una barrera impenetrable.
2. Web Components Encapsulados: Al exportar partes de la UI como Angular Elements, asegura que el registro de los Custom Elements se guarde bajo un prefijo de namespace.
3. Scope de CSS: Usa preprocesadores para envolver el CSS heredado en un wrapper.

/* GA2 Legacy Wrapper */
.legacy-scope {
  @import 'legacy-styles';
}
// Ahora el CSS heredado solo afecta lo que esté dentro de la clase .legacy-scope

4. Observabilidad y Logs de Migración en la UI

Hacer el deploy de la pantalla no significa que la migración fue un éxito. Las bases de datos antiguas (GA2) están llenas de anomalías que el nuevo frontend no prevé.

⚠️ El Escenario de Falla: Contratos Inválidos y Errores Silenciosos

El nuevo componente intenta renderizar user.address.street.toUpperCase(). Como address vino nulo o en un formato inesperado del backend, la aplicación lanza un TypeError y la pantalla muere. El error se pierde en los logs de infraestructura y el cliente abre un ticket quejándose.

La Solución: Frontends defensivos y herramientas de soporte en la propia UI. Usa bibliotecas como Zod (React) para validar el payload en el momento en que cruza la red. Agrega columnas en tu grid de administración del frontend con el estado de la migración y el error exacto que impidió la carga de ese registro.

5. Feature Toggles y la Trampa del Caché

La migración gradual requiere "Botones de Pánico". Controlas quién va a GA3 a través de Feature Flags.

⚠️ El Escenario de Falla: El Fallback que Nunca Ocurre

El manager apaga la flag de un cliente clave porque la nueva versión GA3 presentó un bug, pero el cliente sigue viendo la pantalla rota. ¿El motivo? El Service Worker o el LocalStorage guardó la flag como "activa" y el navegador no busca la nueva configuración en el servidor.

La Solución: Implementa un Guard de enrutamiento con Cache-Busting obligatorio para flags de infraestructura.

// Ejemplo en Angular usando un Guard seguro contra caché
@Injectable({ providedIn: 'root' })
export class MigrationGuard implements CanActivate {
  async canActivate(): Promise<boolean | UrlTree> {
    // Fuerza la petición directa al servidor, evitando cachés de flag
    const flags = await this.featureFlags.fetchLatest({ bypassCache: true });
    
    if (flags['ui-migration-ga3']) return true;
    return this.router.createUrlTree(['/legacy/dashboard']); 
  }
}

El Veredicto

Reescribir un sistema en el frontend no es solo modernizar componentes. Es arquitectura de software enfocada en la gestión de riesgos. Los conflictos de dependencias, la desincronización de tenants, las fugas de estilos entre Elements y las fallas de caché son lo que realmente detiene la operación.

El éxito de tu transición no se medirá por el código que borraste, sino por la estabilidad que mantuviste mientras cambiabas el motor del auto a 120 km/h.

¿Y en tu equipo? ¿Ya han adoptado arquitecturas basadas en Micro-frontends y Web Components para aislar fallas, o todavía sufren con despliegues gigantes? Deja tu experiencia en los comentarios.