node.js

Me atrajo NodeJS desde un principio, cuando oí eso de código de servidor escrito en javascript. Después de aprender las nociones básicas hace un par de años, integrarlo con multitud de módulos y estar a punto de terminar un proyecto completo con este framework, en el que he estado trabajando en el último año, puedo decir que aún viendo sus pros pero también sus contras, sigue siendo para mí una maravillosa plataforma sobre la que construir aplicaciones escalables y mantenibles.

Framework, plataforma, tecnología... se mezclan un poco los conceptos: NodeJS te ofrece el core o framework esencial sobre el que construir aplicaciones, junto con un modelo de programación basado en eventos y una serie de módulos básicos pero muy importantes.

Lo que le da vida realmente a un proyecto con NodeJS es el enorme y vasto ecosistema de módulos que existe a su alrededor, que fueron apareciendo desde el primer momento en que NodeJS salió a escena y que hoy día siguen creciendo y evolucionando.

Esto es algo típico y la tendencia natural en software, como Drupal, Wordpress o el recién salido del horno ASP.NET 5 como framework de aplicaciiones web, sin cuya constelación de módulos que extienden o mejoran su funcionalidad no serían lo que son hoy en día.

Pero no es sólo cuestión de elegir e integrar un conjunto de módulos: es necesario utilizar un grupo de herramientas para una correcta gestión de la configuración de tu proyecto y para la puesta en marcha de los flujos de trabajo que hayas definido, además de aplicar continuamente buenos principios de desarrollo, clean code y una refactorización siempre presentes.

En este proyecto web con un backend bastante pesado en el que llevo trabajando un año he tenido oportunidad de usar NodeJS en profundidad, leyendo multitud de libros, muchos posts y artículos sobre buenas prácticas y buscando y analizando los módulos más populares o maduros para incorporar toda la funcionalidad.

A continuación cuento un poco mi experiencia que básicamente se basa en la pregunta recurrente de cómo hago esto y ahora cómo hago esto otro aún mejor y así hasta que el proyecto comienza a alcanzar cierta madurez, cuando todo el trabajo realizado comienza a converger en algo más palpable y empieza a verse un proyecto que ofrece cierta utilidad, o eso es al menos lo que esperas.

He utilizado una aproximación lean al proyecto, esto es, voy a cerrar un conjunto de funcionalidad muy bien definida y después es el mismo proyecto el que va a validar con los usuarios (los primeros son siempre tus amigos y familiares) si es de alguna utilidad..., si hay que seguir (;-), pivotar (;-| o comenzar otra cosa distinta (;-(.

Me fascina la aproximación lean, ya que en realidad construyes experimentos que después el mercado valida. Si no sabes qué es la aproximación lean de proyectos, comienza leyendo el libro clásido de Eric Ries.

En cuanto a los módulos que estoy usando, los agruparé funcionalmente.

En el core de la aplicación, puedo desglosar los siguientes módulos principales:

• ​Express como framework para lo esencial de una aplicación web. Prácticamente es lo estándar en el mundo NodeJS y posee una enorme constelación de middlewares para la gestión de sesiones (express-session), gestión de los parámetros de un request o post (body-parser), cookies (cookie-parser), enrutado (lo gestiona directamente express), seguridad (protección CSRF con csurf), etc. Aunque hay otras opciones más flexibles, he usado ejs como herramienta de plantillas. También he usado compression para el envío comprimido de los contenidos en cada request.
• Compresión de ficheros con archiver.
• Gestión de imágenes con fabric.js (sí, tiene un módulo que permite usar fabric en el lado del servidor) así como canvas.
• Obtención de valores únicos y hashs con node-uuid, hashids (para la generación elegante de enlaces cortos) y md5 (para crear valores hash a partir de cadenas de texto).
• Framework para logueo de usuarios con Passport; sus extensiones te permiten integrar fácilmente loguee con Facebook, Google+ o Twitter.
• Q como librería para usar promises y evitar el anidamiento de funciones asíncronas (callback hell) que impiden escribir un código legible.
• Cliente para usar Redis como servidor de objetos de caché y almacenamiento en ella de sesiones de usuario.
• Search-index como mecanismo sencillo y útil para indexar los contenidos del site y poder realizar búsquedas.
• Módulo cliente de Sendgrid para el envío de correos electrónicos usando ese mailer.
• cron para gestionar la ejecución de operaciones recurrentes de gestión y mantenimiento del site.
• winston como librería avanzada para mensajes de log.
• Para escribir código más legible y mantenible, he usado profusamente lodash (esto es una oblicación para cualquier desarrollador que use javascript, aunque hay otras opciones similares).
• html-minifier para la minificación de contenidos al ser enviados en cada request.

No es que haya elegido todos esos módulos al azar, sino después de un proceso y trabajo de prueba, evaluación y experimentación, así como leyendo muchos blogs y viendo lo que la comunidad usa con más frecuencia.

¿Y qué hay de las pruebas? Ningún proyecto software puede considerarse maduro y profesional si no está respaldado por pruebas.

Para ello he usado, cómo no, chai como librería de asersiones y mocha para la ejecución de las pruebas. El resultado y la experiencia con ambas librerías ha sido y es magnífico.

El site gestiona multitud de ficheros de diverso tipo (no, no es una página más de enlaces y descargas...), de modo que después de evaluar diversas opciones cloud como CDNs me decanté com Amazon AWS y su paquete aws-sdk para la integración de su API REST en NodeJS.

Del mismo modo, el site se apoya en una base de datos MySql, para lo que he usado el cliente mysql para su integración con la aplicación.

El desarrollo de una aplicación no consiste sólo en hacer que esta funcione, más o menos respaldada por pruebas: también hay que definir flujos de trabajo para generar los assets del proyecto que finalmente serán desplegados en producción.

Para ello he usado, cómo no, grunt y muchos módulos básicos para generar la aplicación para su despliegue. Aunque su mismo nombre indica su propósito, a continuación indico los más relevantes:

Este es el comienzo de un nuevo proyecto. 

Soy de la opinión de que si no eres capaz de explicar a otros aquello que crees que sabes y que usas en el día a día, seguramente no sepas tanto como crees. Enseñar, sea de la forma que sea, mediante posts en un blog, en artículos o en videologs, siempre te permite ahondar aún más en los temas que tratas. Tengo la impresión de que en la cultura anglosajona se fomenta más el mentoring, no es por casualidad, tanto dentro como fuera de la compañía o las empresas en las que trabajas.

Durante 2014 me he metido de lleno en ciertas tecnologías y tendencias relacionadas con conceptos como big-data, responsive design, plataformas para la economía colaborativa, el Internet de las Cosas, etc., al tiempo que me he esforzado aún más en mejorar técnicas de gestión de proyectos software (y que en gran parte consisten en tener una gran empatía con el equipo que dirijes). Como digo siempre, si no mejoras en las competencias con las que trabajas, entonces es que empeoras...

Me gusta NodeJS, lo he empleado este año pasado en un proyecto profesional para un cliente y ahora mismo lo estoy exprimiendo de lleno en uno de mis proyectos para este año. Al mismo tiempo, no encuentro en los pocos libros acerca de NodeJS escritos en castellano todo lo que me gustaría encontrar en ellos; es más, creo que existe una gran laguna que hay que cubrir.

¿Será NodeJS objeto de olvido dentro de unos años?

Aunque en software nunca se pueden hacer predicciones a medio y largo plazo porque no siempre sobreviven las mejores tecnologías, creo que NodeJS y sus derivados va a pervivir con nuestra forma de enfocar proyectos escalables mucho tiempo.

La razón, básicamente, es que es relativamente sencillo de aprender, porque se usa Javascript que es el lenguaje que cada vez está más omnipresente y porque está creciendo alrededor del core un ecosistema de módulos que lo enriquecen enormemente. Por tanto es el momento de preparar en condiciones, con rigor y calidad un buen libro sobre NodeJS.

Pero, ¿otro libro de NodeJS?, ¿será uno más o aportará algún enfoque nuevo?

Existe un gran vacío de literatura técnica en castellano sobre esta tecnología; lo que se encontrar, aún estando muy bien, no deja de ser en mi humilde opinión sencillas introducciones a lo básico de NodeJS sin dar un enfoque global a la realización de un proyecto profesional y listo para salir a un entorno de producción. O sea, que necesitarías varias publicaciones así como muchos artículos y búsquedas en foros para atar todos los cabos y terminar una aplicación mínimamente profesional con NodeJS.

Describir los rudimentos de una tecnología no te prepara para usarla a fondo en un proyecto profesional. Los libros (tanto en castellano como en inglés) que he leído, aún gustándome, carecen de lo siguiente:

• Se presentan siempre ejemplos sencillos y de juguete. Lo cual pedagógicamente está bien pero está lejos de resolver problemas reales, de los que se presentan en cualquier proyecto con NodeJS.
• No se indica cómo implementar técnicas básicas de clean code y refactoring con NodeJS.
• Tampoco se hace hicapié sobre la mejor forma de estructurar un proyecto según la naturaleza de éste.
• No hay un catálogo de buenas prácticas para que un proyecto en el que se emplea total o parcialmente NodeJS se desarrolle con lo que la comunidad acepta como lo más correcto.
• Existe un gran vacío en relación a implementar tácticas de seguridad en un proyecto web realizado con NodeJS.
• Tampoco se encuentran fácilmente las mejores prácticas para desplegar un proyecto con NodeJS en producción de cara a su mantenimiento.
• No se profundiza en ninguno de todos esos módulos que han ido creciendo alrededor de NodeJS y con los que se ha creado un ecosistema realmente rico y maduro para la realización de aplicaciones profesionales (Q y promises, passport, sequelize, async, underscore, lodash, etc.)
• Del mismo modo, no se sugiere cómo usar correctamente un framework de pruebas unitarias con NodeJS y cómo integrarlo bien en cualquier proyecto. 
• Igualmente, tampoco se aclara correctamente cómo hacer una separación de responsabilidades (separation of concerns) en un proyecto con la especial idiosincrasia de NodeJS para su fácil testeabilidad y buen mantenimiento.
• En relación a proyectos web, existen bastantes cosas acerca de Express, pero en pocas se incluyen los elementos necesarios para producir una aplicación web con ficheros css y js, minimizados, concatenados, etc.
• Tampoco se aborda cómo integrar el consumo de recursos externos publicados en forma de servicios REST o cómo construir tu propia capa RESTful.

No es que quiera abarcar todos esos temas con una profundidad tremenda, pero sí con el suficiente detalle como para mostrar una visión global completa.

Así las cosas, hasta ahora si decides meterte de lleno en esta fantástica y prometedora tecnología, que sepas que tendrás que hacerte de alguno de los libros disponibles actualmente y que además tendrás que bucear en multitud de contenidos extra para ver de manera global y holística todo este Universo NodeJS.

De ahí el nombre de Universo NodeJS: no es sólo esa tecnología, su Core API y el uso más o menos avanzado de Javascript (ECMAScript versión 5), sino además multitud de módulos, técnicas y buenas prácticas para el éxito de un proyecto.

¿Cómo se publicará el trabajo?

Los capítulos, ya planteados y organizados, se irán produciendo a lo largo de los próximos meses con una dinámica similar a como fui liberando las secciones de El Libro Negro del Programador: adelantos cada varias semanas de los capítulos con el contenido fundamental hasta completar la publicación del libro con todo el material.

¡Arrrgh! Llevo elucubrando acerca de este proyecto desde hace muchos meses de modo que ahora doy el pistoletazo de salida para contribuir, modestamente, a formar más y mejor a nuestra comunidad de desarrolladores profesionales de software con esta magnífica tecnología.

Recuerda: no somos una simple acumulación de conocimientos sbre esta o aquella tecnología, sino aquello de utilidad que somos capaces de hacer para otros con ellas.

Reconozco que siempre he estado muy interesado en el desarrollo web y, de hecho, hice mis primeras aproximaciones a título personal allá por el 2006 hasta caer en los brazos del magnífico Drupal con el que comencé una start-up (que, como tantas, no terminó de cuajar). Aunque dirijo un grupo de desarrollo como responsabilidad principal en la compañía para la que trabajo, mantengo como uno de mis mantras eso de no desvincularme nunca de la fontanería y conceptos de bajo nivel del desarrollo de software. ¿Cómo si no se puede gestionar un proyecto software si no se conocen con total profundidad los building blocks que lo constituyen? Se puede dirigir, claro, pero entonces el riesgo de tomar malas deciciones, incurrir en desviaciones, etc. será mucho mayor. De esta forma, he seguido siempre de cerca ciertas tendencias, inciativas que han perdurado y otras que cayeron en desuso relacionadas con el mundo web, aún dedicándome casi siempre a realizar aplicaciones pesadas con tecnologías .NET, fundamentalmente.

Cuando decimos que la economía se está moviendo a lo digital, a veces no captamos las implicaciones enormes que tiene esto para un desarrollador profesional de software: significa que se están volcando recursos económicos de manera masiva a la implantación de proyectos empresariales y negocios en Internet y, por tanto, la demanda de buenos profesionales con expertise demostrable será cada vez mayor.

Quedan muy atrás aquellas webs de los noventa casi anecdóticas que apenas eran folletos publicitarios: ahora hablamos de una verdadera industria, desde hace años, que está cambiando el modo en que nos relacionamos y el modo en cómo la tecnología modifica hábitos sociales, como por ejemplo el concepto de economy sharing.

Hay mucho escrito sobre MEAN, de modo que me voy a centrar en las auténticas razones por las que para mí a un desarrollador que conozca bien este stack no le va a faltar trabajo en los próximos años.

Muy brevemente, ¿qué es el stack MEAN?, es un conjunto de tecnologías relacionadas que te ofrecen todo lo necesario para realizar una aplicación web moderna, escalable, testeable y, sobre todo, mantenible (aunque esto último dependerá de las buenas prácticas). MEAN viene de:

• MongoDB, base de datos no relacional. El stack no te obliga, en absoluto, a usar MongoDB, de hecho, actualmente estoy implicado en un proyecto con MySQL + _EAN.
• Express, middleware extraordinariamente sencillo y potente para la generación de aplicaciones web. Se aprende en una tarde, en serio...
• AngularJS, aproximación declarativa al desarrollo de interfaces de usuario extaordinariamente potente. Te permite implementar MVC (o MVVC, depende de los gustos) en el lado del cliente web, de manera que la lógica de presentación, de negocio y las vistas con los modelos están desacopladas. Aquí está lo importante, al poder escribirlas desacopladas, se pueden desarrolar tests contra ellas!. Además, AngularJS es un proyecto de Google.
• NodeJS, framework de servidor con un universo de módulos increíble y en expansión que te permite escribir en javascript aplicaciones de servidor siguiendo un modelo de programación por eventos. NodeJS, como framework, se puede usar para muchos escenarios: uno de ellos (y ni mucho menos el único, aunque se suele confundir) es el desarrollo de aplicaciones web.

Juntando todas las piezas obtienes un stack muy maduro y coherente para escribir aplicaciones web modernas, escalables y testeables; para mí, de los building blocks que constituyen el corazón de este stack, los más relevantes son los middlewares de Express a través del módulo Connect, las directivas de AngularJS y su implementación de MVC, que todo puede ser testeado con Mocha y Karma y, sobre todo, el modelo de desarrollo de NodeJS basado en eventos que te permite olvidarte de problemas de concurrencia y sincronización entre operaciones asíncronas.

Hace varios años, cada vez que volvía a retomar algún proyecto web, me chocaban algunas cosas que no me gustaban en absoluto:

• La manipulación directa y horrorosa del DOM (estamos hablando de hace bastantes años), con todos lo problemas multinavegador.
• Viniendo de un framework pesado como .NET en el que C# daba coherencia a una solución final (front-end, back-end y acceso a repositorios de datos o servicios), me resultaba frustrante tener que usar ciertas tecnologías de cliente y ciertas tecnologías de servidor (javascript, css, html en el lado cliente y php, por ejemplo, en el otro lado del servidor). Esto encarecía enormemente la mantenibilidad de un mismo proyecto.

Con el tiempo fueron surgiendo mejores alternativas de estandarización y maravillosas librerías como jQuery junto con sus widgets, Modernizr, preprocesadores para CSS como Less, Sass y Stylus, etc. que liberaban al desarrollador de los problemas fundamentales y le permitían escribir código de manera más legible, rápida y mantenible. No obstante, existía aún una clara diferencia entre desarrollo web para front-end y el desarrollo del back-end en el servidor, y, de hecho, la mayoría de las aplicaciones web se siguen desarrollando de esa manera.

Hasta que hace unos años leí un artículo sobre un proyecto emergente llamado NodeJS que me dejó confuso: sabía que ahí se había llegado a algo importante aunque ese día no sabía exactamente por qué. Con el tiempo fueron encajando las piezas aunque reconozco que el día que conocí NodeJS sufrí un momento de epifanía..., aún sin saber para qué podía servir.

No hay tecnologías buenas ni malas (resulta hasta infantil las interminables discusiones que si .NET versus Java, que si Oracle versus Sql Server, en fin...), todo depende de la naturaleza del proyecto a realizar y de la solvencia técnica de quien lo implemente (sobre todo lo segundo): un desarrollador especializado en spaguetti software no va a usar bien ningún framework que se ponga por delante, el usar un maravilloso motor de base de datos sin conocerlo suficientemente llevará al traste a una aplicación con consultas mal escritas, etc. A veces se nos olvida que cualquier tecnología o stack de tecnologías tiene su pros y sus contras, y que la mayoría de las veces defenestramos las que no nos gustan por ignorancia de las mismas.

Desde hace un tiempo el stack MEAN para mí ha alcanzado la madurez, seguimiento de mercado y comunidad suficiente como para tomarlo muy pero que muy en serio, es, de hecho, un conjunto de tecnologías emergentes de las que se hablará (y utilizará) muchísimo en los próximos años, de eso no tengo ninguna duda.

Pero, ¿qué aporta este stack?, en mi opinión hay que destacar lo siguiente:

• Te permite escribir una aplicación web de principio a fin usando javascript como único lenguaje, si bien las librerías que se usan en el front-end son distintas, lógicamente, de las que se usan en el lado del back-end con NodeJS.
• AngularJS, bien usado, te libera de la necesidad de manipular directamente el DOM del navegador, permitiéndote escribir de manera declarativa gran parte de la funcionalidad de la interfaz de usuario, pero, sobre todo, desacoplando la lógica del cliente siguiendo el patrón modelo-vista-controlador y por ello permitiéndote escribir tests.
• El stack te permite poder escribir fácilamente aplicaciones SPA (single page application) en las que el cliente web mantiene gran parte de la lógica de aplicación y el lado del servidor implementa la API necesaria para darle soporte, ahorrando así continuos requests http completos de todo el documento html y sus artefactos software.
• Dispones de un alto grado de control de todas las cosas que son de más bajo nivel (gestión de cookies, cabeceras, routing, etc.) pero al mismo tiempo están suficientemente abstraídas para que su uso sea trivial.
• Existen frameworks de tests elegantes tanto para el front-end como para el back-end.
• El despliegue de la aplicación es sencillo.
• Siguiendo las buenas prácticas, es multiplataforma.
• ... y un larguísimo etcétera.

Inconvenientes tiene, claro que sí, pero como cualquier otro stack hay que saber si es conveniente o no para la naturaleza de la aplicación que quieres realizar. La curva de aprendizaje no podemos decir que sea rápida, ya que por poner un ejemplo, AngularJS te obliga a pensar a resolver el cliente web de otra manera y el modelo asíncrono de NodeJS también te obliga a enfocar el lado del servidor con una aproximación mental distinta.