Cómo mantener una aplicación de Node.js en el tiempo - Adrian Estrada

Crear aplicaciones nuevas es emocionante, pero la realidad del desarrollo profesional exige algo muy distinto: mantener proyectos saludables a lo largo del tiempo. Desde la experiencia de trabajar con miles de clientes en NodeSource, queda claro que incluso empresas grandes fallan en esta tarea. Adrián Estrada, VP de ingeniería de NodeSource, contribuidor del core de Node.js y miembro del comité que creó la certificación oficial de Node.js, comparte un plan práctico que aplica no solo a Node, sino a cualquier ecosistema como Python, .NET o Java.

¿Por qué es tan complejo mantener una aplicación de Node.js?

Node.js es una tecnología en constante evolución: cada año se lanzan dos versiones nuevas [01:58]. Además, las aplicaciones dependen fuertemente de módulos de NPM, que resuelven problemas y ahorran tiempo, pero traen riesgos importantes:

• Los módulos son creados por terceros cuya calidad es incierta.
• Una nueva versión puede cambiar el comportamiento del API y romper tu código.
• El árbol de dependencias crece rápidamente porque cada módulo trae sus propias dependencias.
• Se descubren vulnerabilidades de seguridad en código de terceros que afectan directamente tus aplicaciones.
• El cambio de licenciamiento puede hacer que el uso de una dependencia se vuelva ilegal [06:30].

El plan de mantenimiento se divide en tres actividades claras: mantener dependencias, mantener la versión de Node.js y evaluar la arquitectura.

¿Cómo mantener las dependencias actualizadas sin perder productividad?

Una dependencia puede volverse obsoleta cuando su creador pierde interés y deja de publicar versiones [04:15]. Esto genera deuda técnica acumulada que se vuelve cada vez más difícil de resolver.

¿Qué herramientas ayudan con el mantenimiento de dependencias?

• npm outdated: el comando más básico, muestra las dependencias desactualizadas [05:22].
• Dependabot: un bot de GitHub que revisa dependencias y lanza pull requests automáticos cuando hay nuevas versiones. Hay que usarlo con cuidado y siempre testear esos pull requests antes de aceptarlos [05:35].
• Snyk: una suite de seguridad que monitorea vulnerabilidades y versiones de dependencias.
• N Solid y NSM: productos de NodeSource que permiten monitorear cambios tanto en producción como en desarrollo.

¿Cómo planear el mantenimiento de dependencias en cada sprint?

La recomendación es dedicar tiempo en cada ciclo de desarrollo, ya sea con Scrum u otro modelo [06:58]. Se planean tickets para revisar qué hay que actualizar. Las dependencias fáciles se actualizan de inmediato. Cuando una actualización requiere cambios en tu código porque el API de la dependencia cambió, se debe planear esa tarea en el backlog con la misma importancia que un feature nuevo. Si no le das importancia, la deuda técnica crece sin control.

¿Cuándo y cómo actualizar la versión de Node.js?

Existen dos tipos de versiones anuales [08:05]. Las versiones current son números impares (13, 15, 17, 19) y sirven para probar lo más reciente. Las versiones LTS (Long Term Support) son números pares y reciben actualizaciones de seguridad y parches durante al menos dos años. Para producción, siempre use una versión LTS activa.

Dentro de las LTS hay dos estados: la activa, que es la más nueva y puede recibir features sin breaking changes, y la de mantenimiento, que dura aproximadamente un año adicional [08:50].

El proceso de actualización comienza alrededor de septiembre, cuando la nueva versión está por convertirse en LTS [09:30]:

• Instalar la nueva versión y correr el código para observar warnings.
• Identificar APIs deprecadas que tu código o tus dependencias estén usando.
• Verificar que las dependencias se instalan correctamente con la nueva versión.
• Correr todos los tests y analizar resultados.
• Hacer pruebas en staging, un entorno que simule producción.
• Ejecutar pruebas de carga para comparar el performance entre versiones [10:50].

Solo después de completar estos pasos se hace el cambio en producción.

¿Cada cuánto evaluar la arquitectura de la aplicación?

Las dependencias principales, como el framework web (Express, Hapi o Fastify), están presentes en la mayoría del código [11:25]. Si una de estas dependencias deja de mantenerse, el riesgo es enorme. Un caso claro es Express, que dejó de ser mantenido durante mucho tiempo mientras surgían alternativas como Fastify con mejor performance [12:05].

Para evaluar un cambio se debe comprobar que la alternativa tenga buena comunidad, arquitectura compatible, ecosistema maduro, mejor performance y documentación adecuada [12:30]. Este ejercicio se recomienda hacer aproximadamente cada dos años.

El plan completo se resume en tres niveles: dependencias en cada ciclo de desarrollo, versión de Node.js una vez al año por septiembre, y arquitectura cada dos años. ¿Ya tienes un plan de mantenimiento para tus proyectos? Comparte tu experiencia y qué herramientas te han funcionado mejor.