El patrón strangler fig aplicado a frontends
El patrón strangler fig reemplaza un sistema legacy pieza por pieza mientras sigue funcionando. Esta guía muestra cómo opera en un frontend, dónde va el punto de corte y cómo se ve una secuencia real.
La idea en un párrafo
Una higuera estranguladora crece alrededor de un árbol y, con el tiempo, ocupa su lugar. Martin Fowler usó esa imagen para describir una forma de reemplazar sistemas legacy: construir el sistema nuevo en los bordes del antiguo, enviar cada vez más trabajo a las partes nuevas y eliminar las partes viejas a medida que quedan sin uso. En ningún momento hay un día único de cambio.
En un frontend esto significa que los usuarios conservan un solo producto, una sola URL y un solo inicio de sesión mientras cambia el código detrás de cada pantalla.
La decisión clave: dónde va el punto de corte
El patrón necesita un lugar donde una solicitud pueda enviarse al código viejo o al nuevo. En un frontend hay tres lugares prácticos.
| Punto de corte | Cómo funciona | Cuándo encaja |
|---|---|---|
| En el borde | Un reverse proxy o el servidor web envía algunas rutas a la app nueva y el resto a la antigua | Lo viejo y lo nuevo son aplicaciones separadas, o la app antigua se renderiza en el servidor |
| En el shell | Una sola aplicación aloja ambos frameworks y el router decide cuál renderiza cada ruta | AngularJS a Angular con las herramientas oficiales de upgrade |
| Dentro de la página | Los componentes nuevos se montan en páginas antiguas, muchas veces como custom elements | Páginas con mucho jQuery, o frameworks legacy sin puente |
Cómo elegir el punto de corte
- Si la app antigua es AngularJS y el destino es Angular, el corte en el shell suele encajar mejor, porque ambos lados pueden compartir servicios directamente. Los detalles están en Cómo migrar de AngularJS a Angular sin downtime.
- Si los dos lados no pueden correr en la misma página, usa el borde. La navegación entre lo viejo y lo nuevo será una carga completa de página, así que elige límites donde los usuarios rara vez van y vuelven.
- Si las páginas antiguas se renderizan en el servidor con scripts encima, empieza dentro de la página y pasa a páginas completas después. La guía de migración de jQuery sigue ese camino.
Qué deben compartir lo viejo y lo nuevo
El patrón falla cuando los usuarios pueden ver la costura. Hay cuatro cosas que se comparten desde el primer día:
- Sesión. Un solo inicio de sesión. Ambos lados leen el mismo token o cookie y reaccionan igual cuando expira.
- Navegación. Un solo menú y un solo conjunto de URLs. Los enlaces profundos y el botón atrás se comportan como antes.
- Apariencia. Estilos o design tokens compartidos, para que una pantalla migrada no parezca otro producto.
- Capa de datos. Una sola fuente para el usuario actual, los permisos y la configuración. Dos copias del mismo estado producen errores difíciles de reproducir.
Una secuencia de ejemplo
Toma una app de gestión de pedidos con cinco áreas: dashboard, pedidos, clientes, reportes y configuración.
- Inventario y punto de corte. Lista las pantallas de cada área. Elige el corte en el shell. Decide que reportes es el piloto, porque es de solo lectura y está aislado.
- Construir el shell. La aplicación nueva arranca primero y carga adentro la app legacy. Las rutas desconocidas caen al router legacy. Los usuarios no notan nada.
- Compartir la infraestructura. Mueve la autenticación y la capa HTTP al lado nuevo y exponlas al lado legacy.
- Estrangular la primera ruta. Reconstruye el listado de reportes en el framework nuevo. Pon la ruta detrás de un interruptor. Publícala para usuarios internos y luego para todos.
- Borrar. Cuando reportes esté estable, elimina su código legacy. La app antigua ya es más pequeña.
- Repetir por área. Sigue configuración y luego clientes. Cada área repite los mismos pasos: reconstruir, cambiar, observar, borrar.
- Tomar el centro. Pedidos es el área más usada y más compleja. Va tarde, cuando los patrones están probados y el equipo es rápido.
- Reemplazar el marco. Mueve la navegación, el layout y el login al lado nuevo.
- Eliminar el árbol original. Ninguna ruta llega a la app legacy. Bórrala, junto con el router antiguo y el puente entre ambos.
Cada paso numerado se publica por separado. Las funcionalidades siguen avanzando en todas las áreas que no se están migrando en ese momento.
Errores comunes
- Estrangular por capa técnica. Migrar "todos los servicios" o "todos los formularios" no entrega nada que los usuarios vean. Estrangula por ruta o por área de negocio.
- No borrar nunca. Si la versión antigua de una pantalla se queda después de publicar la nueva, el árbol nunca muere y mantienes las dos.
- Una costura con filtraciones. Código viejo que se mete en componentes nuevos, o al revés, a través de variables globales. Mantén la superficie de contacto pequeña y explícita.
- Sin condición de término. Define al inicio qué significa "el árbol original desapareció" y planifica la limpieza.
Cuándo el patrón es la herramienta equivocada
En una app pequeña que un desarrollador puede reconstruir en pocas semanas, el punto de corte cuesta más de lo que ahorra. Una reescritura directa es más simple. La comparación está en Reescribir, híbrido o microfrontends.
Más en esta sección
- Feature flags y cambios de ruta en una migración incremental
- Salir de AngularJS: ¿Angular o React?
- Migrar una app con mucho jQuery a un framework de componentes
- Migrar aplicaciones Backbone, Knockout y Ember antiguas
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn