Migrar aplicaciones Backbone, Knockout y Ember antiguas

AngularJS se lleva la mayor parte de la atención, y está lejos de ser el único framework legacy. Las apps en Backbone, Knockout y las primeras versiones de Ember siguen los mismos principios de migración, con otros puntos de corte y otras trampas.

Los mismos principios aplican

Sea cual sea el framework legacy, una migración segura tiene la misma forma:

1. Inventario de pantallas, código compartido y plugins de terceros. Borra lo que no se usa.
2. Elegir un punto de corte donde se encuentran el código viejo y el nuevo.
3. Compartir la sesión, la navegación y los estilos, para que los usuarios vean un solo producto.
4. Mover una pantalla o una zona a la vez, publicada detrás de un interruptor.
5. Borrar la versión antigua de cada pieza cuando la nueva esté estable.
6. Eliminar el framework legacy al final.

Este es el patrón strangler fig. Lo que cambia con cada framework es dónde puede ir el punto de corte y cuánto del código antiguo se aprovecha.

La diferencia principal con AngularJS

AngularJS tiene herramientas oficiales de upgrade que le permiten compartir una misma aplicación con Angular moderno. Backbone, Knockout y Ember no tienen un puente equivalente hacia Angular o React. La convivencia se arma con herramientas generales:

• Cambio a nivel de ruta en el servidor o el proxy, donde algunas URLs van a la app nueva.
• Custom elements, con los que los componentes nuevos se montan dentro de páginas antiguas.
• Una capa compartida delgada para sesión y eventos, escrita por tu equipo.

Es más infraestructura que construyes por tu cuenta. A cambio, los dos lados quedan poco acoplados, y eso facilita la eliminación final.

Backbone

Cómo son estas apps. Backbone entrega modelos, colecciones, vistas, un router y eventos, y deja el resto en tus manos. Por eso cada app Backbone tiene su propia arquitectura. Muchas agregan Marionette para tener estructura. Las vistas renderizan templates a mano y actualizan el DOM con jQuery.

Qué se aprovecha

• Los modelos y colecciones se traducen bien a servicios tipados y objetos de datos simples.
• El router es simple y convive fácil con otro router, siempre que cada uno sea dueño de rutas distintas.
• Las convenciones REST de los modelos Backbone suelen significar que el API ya es JSON limpio.

Qué exige cuidado

• Las vistas mezclan renderizado, manejo de eventos y reglas de negocio. Lee cada una antes de estimar.
• El bus global de eventos. Mapea quién publica y quién escucha antes de mover cualquiera de los dos lados.

Punto de corte típico. Custom elements dentro de vistas Backbone para las primeras piezas, y después rutas completas.

Knockout

Cómo son estas apps. Knockout enlaza view models con HTML mediante atributos data-bind y observables. Suele vivir dentro de páginas renderizadas en el servidor, sobre todo en aplicaciones ASP.NET MVC, con un view model por página y sin router en el cliente.

Qué se aprovecha

• Los view models ya están separados del markup. Sus observables y valores computados se traducen con naturalidad a estado de componentes, y a signals en el Angular actual.
• Cada página es independiente, lo que entrega unidades naturales de migración.

Qué exige cuidado

• Los templates son vistas de servidor con bindings adentro. Hay que separar la parte de servidor de la parte de cliente, como en la guía de AngularJS con ASP.NET MVC.
• Los binding handlers propios suelen envolver plugins de jQuery. Cada uno necesita una decisión: reemplazar o envolver.
• Los datos muchas veces los inyecta el servidor en la página. Necesitan endpoints JSON.

Punto de corte típico. Página por página en el servidor. En páginas grandes, islas de componentes dentro de la página, como en la guía de migración de jQuery.

Ember 1.x y 2.x

Cómo son estas apps. Ember es un framework completo con convenciones fuertes: su propio router, su propia capa de datos en Ember Data, su propia herramienta de build y una estructura de proyecto fija. Las apps Ember antiguas suelen ser single-page applications reales, con estructura consistente.

Una opción que los otros no tienen. Ember sigue en desarrollo activo y tiene un camino de actualización documentado a través de sus versiones de soporte extendido. Si el equipo está conforme con Ember, actualizar en el mismo framework es una opción legítima. Desde 1.x es un camino largo, con muchas deprecaciones por resolver, y evita cambiar de framework. Compáralo con honestidad frente a una migración antes de decidir.

Qué se aprovecha, si dejas Ember

• La estructura de rutas. Las apps Ember se organizan por ruta, lo que entrega una lista clara de unidades de migración.

Qué exige cuidado

• Ember es dueño de toda la página y de la URL. Incrustar piezas de otro framework adentro es más difícil que con Backbone o Knockout.
• Ember Data da forma al contrato del API. Revisa si el backend sigue de cerca sus convenciones y qué debe reproducir la nueva capa de datos.

Punto de corte típico. Cambio a nivel de ruta en el borde, con sesión compartida y una barra de navegación que se ve igual en ambos lados.

Más en esta sección

• Migrar AngularJS que vive dentro de ASP.NET MVC
• Migrar AngularJS que vive dentro de Java y JSP
• Cómo seguir entregando funcionalidades durante una migración
• Cómo medir el avance de una migración