MÁS ALLA DE LOS MOBILE SERVICES: Una nueva era en el backend

Update:

Descarga la presentación PPT de este post de aquí:

Y el código de ejemplo de aquí

Seguramente ya has trabajado algo con Azure Mobile Services (en este artículo ZuMo) o al menos los has oído nombrar y sabes que son usados para que tus apps puedan acceder fácilmente a un backend a través de llamados http o de apis nativas en las plataformas de desarrollo de esas apps que lo encapsulan.

Eso a simple vista suena muy sencillo y directo, pero en realidad nos estamos enfrentando a todo un nuevo paradigma de desarrollo que cambia las reglas y las formas en que se hacen las cosas, sobre todo para nosotros los desarrolladores que venimos del mundo .net tradicional.

Con ZuMo podemos tratar escenarios tan abstraídos y sencillos como insertar datos en una tabla de SQL Database, reaccionar ante un update o enviar una push Notification:

Pero no estamos restringidos solo a estas operaciones básicas. Hoy en día a través de ZuMo podemos generar APIs personalizadas que podemos llamar cuando queramos. Podemos establecer Jobs que se ejecuten automática y periódicamente; podemos aprovechar los mecanismos de autenticación provistos out of the box y mantener el código y desplegarlo con GIT, entre muchas otras características provistas por esta plataforma que aprovecha lo mejor de Azure.

En síntesis, hemos pasado de proveer un mecanismo que nos permitía guardar datos en la nube con cierta lógica, a tener todo un servidor de Backend para aplicaciones conectadas. Y obsérvese que no usé el término APPs, sino aplicaciones. Quiero decir entonces que esto no solo es para los móviles. Es tan robusto el esquema ofrecido por ZuMo, que claramente puede apoyar aplicaciones web, escritorio, etc. para ejecutar tareas específicas.

De hecho, en ocasiones como lo veremos en este artículo, TODO el backend puede dejarse en manos de mobile services y así proveer funcionalidad a clientes web, móviles y lo que sea que pueda establecer una conexión HTTP. Y lo mejor de todo, es que esto se logra con ventajas sobre los modelos tradicionales.

Qué ventajas se pueden obtener de un backend?

1. Performance en la ejecución

2. Performance en el storage

3. Capacidad de storage

4. Simplicidad de desarrollo

5. Ahorro$

Y en Azure qué elementos proveen estas ventajas?

1. Servidores nodejs en Mobile Services

2. Azure Storage (tables, queues, blobs; particularmente: tables con su esquema NoSQL)

Estos dos elementos tienen un performance sin igual comparado con esquemas tradicionales como los obtenidos con servidores ASP.NET o SQL Server. Adicionalmente el costo es mucho menor,

Esto sucede ya que nodejs o el Azure storage no están enriquecidos con todas las abstracciones, características y herramientas adicionales que traen unos servidores tan robustos como IIS o SQL Server.

Por ende, la ejecución es más veloz y los costos mucho menores!

Son más bien elementos muy básicos que hacen extremadamente bien lo “poco” que hacen. Y esto nos lleva entonces a ver que tampoco es que sean la receta mágica de todo backend. Son más bien elementos que resuelven muy bien cierto tipo de problemas, al contrario de los servidores tradicionales que han sido construidos tratando que puedan solucionar todo tipo de problemas. Precisamente esto es lo que los convierte en piezas de software muy grandes que consumen muchos recursos y que pueden resultar más costosas.

Esto no implica entonces que hoy en día no sigan siendo súper relevantes los servidores tradicionales (como IIS o SQL). De hecho imagínate construir todo un ERP encima de un modelo NoSQL donde no hay manejo de integridad referencial incluido en la herramienta. Eso es reinventar la rueda. Y ni hablar por ejemplo de la administración de conexiones y seguridad en los servicios que provee automáticamente IIS: en últimas tendrías que volver a escribir estos servidores para que hagan todo esto que ya se ha resuelto.

El asunto es que hay tareas que no requieren de toda esta parafernalia. Por ejemplo una app que ofrezca resultados deportivos alrededor del mundo. Que se pueda ejecutar desde cualquier dispositivo o internet browser.

Si lo pensamos, el modelo de datos es relativamente sencillo. Solo hay unas pocas entidades. Así que mapearlo en un esquema NoSQL, aunque es más complicado que mapearlo en un modelo E-R, no es una cosa imposible o muy difícil de hacer.

Como es una aplicación abierta al público en general, el manejo de seguridad es bien sencillo. Además la funcionalidad la podemos mapear en sencillos métodos que ejecutan procesos sobre los datos almacenados. Estos métodos pueden ser escritos dentro de las apis personalizadas de mobile services y entonces ser llamados desde cualquier lugar del mundo a través de HTTP. Esto sin mencionar que ZuMo ofrece mecanismos de autenticación integrada con Facebook, Twitter, Google, Active Directory y la posibilidad de generar nuestros propios mecanismos.

Obsérvese que al ser esta una aplicación mundial abierta al público, se espera una gran cantidad de peticiones por unidad de tiempo. Pero al estar todo montado en nodejs, podremos responderlas sin mucho problema y escalar de acuerdo a las poderosas ventajas ofrecidas por Microsoft Azure. El storage podrá almacenar inmensas cantidades de información (centenares de teras) y de acuerdo a cómo se hayan creado las tablas, ofrecerá unos tiempos de consulta inalcanzables por cualquier motor relacional de bases de datos (cosa que pasa por ejemplo con twitter o Facebook).

Es este entonces un escenario propicio para implementar usando este nuevo paradigma de desarrollo en el cual se provee la lógica gruesa de la aplicación en un servidor nodejs para que los clientes (apps o browsers) puedan acceder a ella y el código que necesiten internamente sea mínimo. Facilitando por ende la engorrosa tarea de la portabilidad y esta es otra inmensa ventaja que sale naturalmente a través de este cambio.

Con lo anterior solo bastaría hacer ciertas salvedades antes de dar el paso e ir a programar nuestro backend con nodejs en Mobile Services y Azure table storage.

1. Mobile Services YA soporta .net como plataforma, a través de WebAPI. Esto permite que el desarrollador pueda hacer su backend sin necesidad de aprender nodejs. Pero como la arquitectura .net es distinta a la nodejs, entonces no se tendrán las ventajas de performance obtenidas con nodejs.

2. Mobile Services SIEMPRE ha soportado SQL Database. Así que si se requiere generar un backend contra un modelo relacional tradicional (el desarrollo es más sencillo), no hay ningún problema.

3. Desarrollar para nodejs y Azure table storage no es tan sencillo como desarrollar .net sobre un modelo relacional. Muchas abstracciones del modelo tradicional no se encuentran en nodejs ni el table storage. Así que en general habrá que esforzarse un poco más en el desarrollo y entender muy bien los conceptos de la arquitectura de un único hilo que no se bloquea en nodejs o de la forma en que las tablas nosql trabajan.

4. No existe un IDE completo que abarque todo el ciclo de desarrollo con nodejs y Azure Storage. Por ejemplo con Visual Studio y ninguna otra herramienta adicional, es posible construir toda una aplicación cliente servidor desde la misma base de datos, pasando por la lógica de negocio, hasta el cliente web y las apps Windows. De hecho aunque el soporte a Javascript ha mejorado enormemente aún siguen habiendo algunas falencias:

i. La habilidad de tener un tipo de proyecto que sea solo JavaScript: Esto se puede emular con un proyecto de tipo web, pero no es tan práctico

ii. Incluir un ejecutor de scripts que use por ejemplo el intérprete de nodejs integrado: Emulable usando la Nugget Package Manager console para ejecutar los scripts.

iii. No existe una integración visual con GIT para mantener y desplegar el código a Azure: Emulable usando la Nugget Package Manager console para ejecutar los comandos de GIT pero no en modo visual.

iv. No existe un debugging difuso en tiempo de diseño para minimizar errores en un lenguaje interpretado como JavaScript: Update: El update 2 de Visual Studio 2013 ya incluye JSHint integrado en la edición de JavaScript, que permite tener más confianza y velocidad en el JavaScript que escribimos a través de su analizador de código estático:

5. No existe un cliente REST integrado para hacer testing rápido de los Servicios: Se puede usar una herramienta separada como Fiddler o Postman para hacer este testing, o tal vez usar curl desde la consola de NPM.

Dadas todas estas condiciones recomiendo altamente usar un editor Javascript avanzado mientras existe más soporte en Visual Studio para lo que podríamos llamar proyectos Javascript o nodejs como tal. Una buena alternativa sería WebStorm, aunque no es gratuito, pero tiene versiones para Windows, Linux y Mac y posee todas las características descritas anteriormente.

Adicionalmente para operar rápida y eficientemente el Azure Storage, recomiendo ampliamente Azure Management Studio de Cerebrata. Que a pesar de no ser gratuito ofrece numerosas ventajas para tener un buen entorno de desarrollo sobre el cloud en la parte del storage. Una alternativa gratuita podría ser Azure Storage Explorer.

La metodología descrita hasta ahora, la he sumarizado luego de desarrollar varios proyectos sobretodo enfocados a aplicaciones móviles. Y para darle identidad, he creado el término nojats. Una aplicación nojats, está hosteada en Azure, tiene su backend en nodejs (noj) y el almaceniamiento lo maneja con el Azure Table Storage (ats).

Así que luego de esta introducción a las aplicaciones nojats, en posteriores posts, estaré mostrando más detalles de cómo optimizar el ambiente de desarrollo para explotar al máximo todas las ventajas que les he mencionado.

Particularmente mostraré en la siguiente entrega cómo usar WebStorm para optimizar el trabajo con JavaScript Azure Mobile Services.