stack mean

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.