Llegamos a ustedes gracias a:



Reportajes y análisis

Node.js se vuelve profesional

Nuevas oportunidades y riesgos

[06/03/2015] En sus apenas cinco años de existencia, Node.js se ha transformado de una curiosidad tecnológica a una pila de tecnología por sí misma, ofreciendo importantes bloques de construcción para todo, desde microservicios hasta APIs.

La mejor parte del crecimiento se debe al ecosistema de herramientas, los entornos de desarrollo, y los servicios de hosting que han evolucionado alrededor de Node.js en respuesta a la necesidad de hacer amigables a las herramientas de desarrollo actuales (como Visual Studio), y de ofrecer Node.js con el soporte y servicio de nivel profesional que se requiere.

Pero afinar las herramientas de manera específica a las necesidades de las apps Node.js da una vista más granular de la salud del ecosistema Node.js, mostrando tanto cuán lejos ha llegado Node.js y cuán lejos puede llegar aún.

El alto perfil se aleja de Node.js, incluyendo la reciente introducción de una variante, amplificando no solo las limitaciones del ecosistema Node.js, sino también la dirección en la cual el ecosistema debe evolucionar.

He aquí un vistazo al futuro de Node.js, como se ve en los desarrollos emergentes actuales.

Entornos de desarrollo: Desiguales y mirando más allá del IDE tradicional

No es de sorprender que los entornos de desarrollo de JavaScript desde hace tiempo hayan girado en torno a la creación y depuración y de JavaScript como un asunto del lado del cliente. Aunque las consolas de JavaScript en Chrome y Firefox ofrecen una interfaz REPL, entre otras herramientas de depuración, están principalmente orientadas a satisfacer las necesidades del cliente, no del servidor o de los desarrolladores.

Para aquellos que buscan cómo usar el JavaScript más allá del cliente, están surgiendo herramientas de creación y de depuración intrigantes. Un proyecto de StrongLoop, fabricantes de una pila de herramientas de desarrollo Node.js, permitirá a desarrolladores experimentados potenciar herramientas de depuración JavaScript en el front-end para la depuración de Node.js en el back end. El Node.js Inspector se conecta al Developers Tools de Chrome dentro de una instancia corriendo Node.js, permitiendo su inspección, punto de quiebre, paso a través, navegación de archivos fuente, y funcionalidad REPL para trabajar directamente con las apps Node.js. Aun no realiza perfiles, sin embargo, aunque hay otro proyecto en camino para satisfacer esa necesidad (Node.js Webkit Agent), también está en gran medida incompleto, y solo ejecuta perfiles y uso de CPU para apps Node.js.

Cuando se trata de los IDEs, el panorama es un poco más optimista. Por un lado, la mayoría de IDE profesionales tiene no solo soporte JavaScript, sino soporte Node.js; aquí, Visual Studio y Eclipse lideran el paquete. Aunque claramente ellos favorecen el ecosistema de Microsoft, las herramientas Node.js para Visual Studio, por ejemplo, cuentan ahora con depuración local y remota, soporte NPM, y muchas otras funciones requeridas por los desarrolladores de Node.js.

Fuera del sandbox convencional de IDE, están ocurriendo cosas interesantes con el Node.js.

Considere el Node-RED de IBM, ofrecido como una "herramienta visual para cablear la Internet de las cosas. Con el Node-RED, el código está cableado junto en diagramas de flujo o visuales que muestran cómo están conectados los "dispositivos de hardware, APIs, y los servicios en línea. Obviamente, la programación no está hecha solamente con flujos; hay una copia de Eclipse incrustada dentro de Node-RED para escribir JavaScript. No parece probable que todas las apps Node.js pudieran ser creadas o editadas de esta forma, pero es un ejemplo de cómo el Node.js está inspirando nuevos enfoques para herramientas de desarrollo que miran más allá del IDE convencional.

Hosting: la competencia estimula el soporte y la innovación en la nube

Antes de que Node.js comenzara a avanzar seriamente, la única forma de ejecutar Node.js era desplegarlo en el bare metal que uno tuviera. Esos tiempos ya pasaron hace rato, y los proveedores de nube ahora están subiendo unos sobre otros para ofrecer hosting Node.js -no solo soporte para Node.js en VMs, sino hosting PaaS completo para Node.js.

La mayoría de marcas de PaaS ahora ofrecen soporte para Node.js, y aquellas que tuvieron un inicio temprano han hecho todo lo posible para reforzar su soporte. Heroku, por ejemplo, no solo permite desplegar apps Node.js, sino que uno puede elegir qué versión de Node.js o NPM usar (incluyendo las versiones más nuevas, no necesariamente soportadas). Amazon, por otro lado, ha usado el pretexto de soporte similar a PaaS para Node.js para crear una nueva clase de servicio de programación funcional completamente nuevo: AWS Lambda.

Debido a que Node.js y JavaScript no son manejados por eventos, Amazon pensó ¿por qué no crear una mini pila para Node.js que ejecute código en respuesta a eventos en cola desde el resto del AWS?

Amazon ya tenía experiencia enganchando el Node.js a sus servicios a través de un SDK que permitía llamadas al AWS a través del Node.js, pero el AWS Lambda dio un salto aún mayor dentro del territorio de Node.js. No es probable que este uso altamente enfocado del JavaScript produzca la demanda de la que gusta la pila Node.js, pero Lambda es intrigante. Amazon está claramente interesado en qué otros frutos pueden dar este enfoque, ya que tiene planes tentativos para añadir soporte a otros lenguajes para Lambda en el camino.

Otro cambio fundamental en la forma en que Node.js trabaja con los hosts ha venido con la llegada de Docker, la tecnología de aplicación de la contenerización de aplicación al rojo vivo. Docker ofrece una manera sencilla de combinar el tiempo de ejecución del Node.js con su código, datos y otras aplicaciones asociadas, lo cual quiere decir que todas las dependencias requeridas por la aplicación -incluyendo la versión específica de Node requerida para ello- no tienen que ser soportadas por el host.

Docker también ofrece formas convenientes de crear apps Node.js y de escalarlas (como a través de código abierto Deis PaaS). Y un paquete NPM para Docker, el dnt, permite a Docker ser usado para testear código contra múltiples versiones de Node.js en paralelo.

Dados estos desarrollos, las opciones de hosting de Node probablemente van a proliferar avanzando. Aquí, la contenerización es fundamental, ya que hace posible que los desarrolladores ejecuten Node.js en sus servicios host sin que siquiera el host tenga que soportar los tiempos de ejecución de la aplicación de Node elegida. Pero así como se ve en el Lambda de Amazon, el soporte para Node.js, también puede cosechar recompensas para proveedores de hosting que busquen potenciar la API Node para construir nuevos servicios y productos.

Testeo y depuración: el talón de Aquiles de Node.js

Aquí, una de las más grandes limitaciones es la forma en que la API de depuración, presente en el motor V8 en el núcleo de Node.js, ha quedado sistemáticamente detrás del V8 mismo. Ugur Kadakal de Nubisa, fabricante de la variante JXcore de Node.js, anotó que aunque la función Promises de JavaScript ha sido soportada en V8 por algún tiempo, el depurador V8 sigue fallando cuando se utiliza.

Joyent, a través de Joyent Private Cloud y Joyent Compute Service, ha desarrollado su propia solución a los problemas con la depuración de Node.js. El más incómodo de estos problemas es el consumo de memoria.

"Históricamente -señala Bryan Cantril, director de tecnología en Joyent- tenemos poca idea de cómo se utiliza la memoria en ambientes dinámicos.

Para tal fin, Joyent incluyó soporte de depuración de Node.js inside-out en su plataforma, a través del impulso de la función DTrace del SmartOS derivado del Solaris, de Joyent, sobre el cual está construida la plataforma. La mala noticia es que cualquiera que desee usar el mismo juego de herramientas necesita ejecutar el SmartOS, ya sea por su cuenta o a través de la nube de Joyent. Cantrill no descartó la posibilidad de que la tecnología de depuración pudiera ser portada a otras plataformas, pero admitió que tiene un montón de dependencias en SmartOS que necesitarían ser resueltas.

El testeo de frameworks representa otra área para posibles mejoras. Bowery, creador de un sistema de entorno de desarrollo de nube, construyó la primera versión de su servicio en Node.js, pero eventualmente lo cambió a Go por una serie de razones. Entre ellas estaba el hecho de que algunos frameworks de testeo para Node.js "trabajaban mejor en el front-end, como Jasmine, y otros eran mejores en el back-end, como Mocha. Con Go, razonaron, el testeo está construido y estandarizado en todos los ámbitos; Node.js se podría beneficiar de tener que probar un framework de una robustez similar.

Una salida de alto nivel del mundo del desarrollo de Node.js fue estimulada por las limitaciones actuales en la depuración y el desarrollo de aplicaciones Node.js. TJ Holowaychuk, creador del Koa, Express, y el proyecto Node.js-canvas, escribió un ensayo en junio del 2014 en el que se despidió, cariñosamente, del desarrollo de Node.js y su entorno que "privilegia el rendimiento sobre la usabilidad y la robustez. El manejo de la depuración y errores, especialmente para los callbacks -uno de los comportamientos del núcleo del Node.js- lo considera poco desarrollado.

Para Holowaychuk, el Node.js es un proyecto poderoso que vale la pena, pero "el rendimiento no significa nada si su aplicación es frágil, difícil de depurar, refactorizar y desarrollar. Holowaychuk manifestó su confianza en que estos problemas se pueden superar con el tiempo.

Una variante y el futuro

En teoría, un proyecto de código abierto como Node.js debería desarrollarse a pasos agigantados, con problemas como los descritos aquí, atacados en el corto plazo. Sin embargo, en la práctica, algunas partes del Node.js no han evolucionado tan rápidamente como otras. Aparte de la depuración y la inspección, han aparecido preocupaciones acerca del ritmo de desarrollo del Node, como se evidenció en los problemas de ciclo de lanzamiento el año pasado. Los planes de Joyent para solucionar esto solo fueron claros recientemente. La versión 0.12 de Node finalmente fue entregada en febrero del 2015 con mejoras en la vena de arriba, y se ha configurado un Node.js Foundation separado para mover la gobernanza hacia una tercera parte desinteresada.

Sin embargo, antes de eso, otros dieron sus propios pasos. Una variante del proyecto Node.js, llamado io.js, nació como una forma de solucionar la depuración, los lentos ciclos de lanzamiento, y la gobernanza, entre otros problemas.

Otros planes incluyen agregar funciones de seguimiento al Node.js en Linux, y usar una versión más reciente en el motor JavaScript V8 para "integrarse con las últimas herramientas de depuración que Google ha hecho para Chrome y aprovechar el trabajo que han hecho mejorando la depuración.

"La depuración siempre ha sido un desafío en entornos asíncronos, señaló Rogers, "pero estamos haciendo progresos.

Io.js aún es joven, aunque unos cuantos despliegues de Node.js ya se han dado (Uber es una de las más prominentes organizaciones en hacerlo). Pero ya sea que esos avances y más como ellos vengan de Io.js o de Node.js en sí mismo, está claro que los cambios son muy necesarios para que Node.js florezca aún más.