Es poco frecuente que una app móvil sea independiente del mundo exterior y no necesite comunicarse. Tal vez sea el caso de algunos juegos casuales o utilidades sencillas. Sin embargo, la inmensa mayoría de las apps precisan compartir datos con el mundo exterior, ya sea como productoras, consumidoras o, frecuentemente, ambos roles.

Para ello utilizaremos un backend. Es posible que ya dispongamos de uno en la empresa y queramos optimizarlo o que debamos empezar de cero. En ambos casos un Backend específico para movilidad podrá ayudarnos. Pero, ¿son todos iguales? ¿existen opciones avanzadas entre las ofertas del mercado? Profundicemos en ello.

¿Que es un mBaaS?

Un mBaaS (mobile Backend as a service) es un backend optimizado para cubrir las necesidades de las apps móviles y desplegado como una serie de servicios en la nube que podemos utilizar conjunta o independientemente.

Estos servicios deben ser accesibles de manera sencilla y unificada, liberando al desarrollador de las complejidades internas. Además deben soportar las peculiaridades del acceso móvil, como desconexiones, trabajo offline, inmediatez, diferentes plataformas, etc.

Un mBaaS no es simplemente una API, nos proporciona un conjunto de servicios que cubren las diferentes necesidades de la app. En el apartado siguiente veremos los más comunes.

¿Qué esperamos de un mBaaS?

La finalidad de un mBaaS es facilitarnos el desarrollo de aplicaciones móviles (apps). Para ello nos debe proporcionar las herramientas básicas:

• SDK**:** Librería de fácil integración y uso que nos dé acceso a las funciones proporcionadas por el mBaaS. Nos aísla de las complejidades de comunicación, conectividad y multitarea. Debe estar disponible para la mayor cantidad posible de plataformas. Al menos Android, iOS y Javascript, pero sería deseable que soportara Xamarin, Windows Phone...
• Analiticas**:** ¿Cómo están utilizando los usuarios la app? Es imprescindible tener una monitorización de propiedades del usuario y eventos de uso.
• Crash reporting**:** Crashes y bloqueos son la principal causa de desinstalación de una aplicación. Y en el mundo móvil suceden fuera de nuestro control. Necesitamos estar informados de cuándo y dónde surgen los problemas.

La práctica totalidad de las apps necesitan compartir datos, a menudo sólo entre sus usuarios como en el caso de muchos juegos, compra venta, etc. Incluso para estos casos simples y, por supuesto, para los de mayor envergadura necesitaremos:

• Servicios de autenticación**:** Nos debe permitir la autenticación basada en usuario (email) / password, OAuth integrado con Google, Facebook, Twitter… O integrar nuestro propio sistema de autenticación.
• Almacenamiento**:** Espacio donde guardar y compartir ficheros, vídeo, imágenes, documentos...
• Base de datos**:** Almacenamiento NoSQL de fácil uso y que permita la sincronización bidireccional.

A medida que las aplicaciones crecen en funcionalidad, precisan de otras características que debería tener todo mBaaS que consideremos:

• Push notifications**:** Nos permite enviar notificaciones a la app cuando necesitamos comunicar algo al usuario o sincronizar algún dato.
• Dashboard**:** Control de todo el mBaaS, desde la creación de usuarios o los modelos de base de datos a la monitorización de las estadísticas.
• Funciones en la nube**:** Automatización de tareas. Disparo de notificaciones en función de triggers, batch jobs periódicos...

Otras funcionalidades útiles, aunque menos imprescindibles:

• Mensajería cloud**:** Mensajería entre las apps y plataformas. Simplifica la comunicación y sincronización de usuarios y apps sin necesidad de apoyarse en notificaciones push.
• Hosting**:** Dónde situar pequeñas aplicaciones para backoffice, etc. Nos ahorra tener que contratar servidores adicionales.
• A/B Testing, invitaciones...****: Herramientas de marketing para incrementar el éxito de las apps.
• Test Lab**:** Prueba de nuestras aplicaciones en dispositivos reales o emulados de distintos formatos y plataformas sin necesidad de disponer de ellos físicamente y de manera automatizada.
• Links dinámicos**:** Apertura de nuestras apps en cualquier punto mediante notificaciones o links enviados por email o SMS.
• Y muchos más**:** Anuncios, SEO…

Hace unos años, al pensar en mobile backend, pensábamos en Parse, hasta que nos lo quitaron. Otros han ocupado su sitio, y entre ellos Google aporta Firebase, con buenas características y que recientemente incluso ha añadido la posibilidad de alojar código en el servidor.

Pero aquí falta algo…

Todo esto está muy bien para las aplicaciones autocontenidas. Pero, ¿qué ocurre cuando tenemos que acceder a los datos corporativos?

Si hay suerte, la empresa tiene un API Gateway que proporciona acceso a sus datos corporativos. En el mejor de los casos, este API está desarrollado para una página web de funcionalidad similar a la de nuestra app o, incluso mejor, se va a crear un API Gateway para la ocasión y podremos influir en su diseño para optimizar la parte que nos atañe a las apps.

Luego tendremos que crear el acceso a este API mediante nuestro propio código independiente del SDK utilizado para el mBaaS. Añadiremos las librerías necesarias como Alamofire o Retrofit, configuraremos endpoints, servicios, etc.

Es posible que nos proporcionen una definición del API en YAML y podamos automatizar parte de este proceso mediante Swagger-codegen ahorrándonos mucho trabajo.

Pero siempre nos encontraremos con las mismas dificultades:

• Deberemos crear estos clientes de la API para cada una de nuestras plataformas: iOS, Android, Xamarin, Cordova… multiplicando el trabajo.
• Cualquier cambio en la API nos causará problemas: ¿mantenemos versiones de API en el servidor? ¿actualizaciones de la app obligatorias?
• El uso de un cliente API y un acceso al mBaaS por separado exigirá compromisos no óptimos. Los desarrolladores deberán conocer dos entornos separados y no siempre será posible integrarlos de manera ideal.

Y la cosa se puede poner aún peor…

Es posible que nuestro cliente no disponga de un API Gateway o que esté pensado para unos servicios muy diferentes de los que necesitará nuestra aplicación. Las empresas han ido cambiando sus sistemas con el paso del tiempo, integrándose con otras empresas y probando diversas soluciones de software.

El API que construyeron tal vez se pensó para que los empleados pudieran acceder al ERP corporativo y exige decenas de llamadas para construir una pantalla de nuestra app. O tal vez los sistemas de autenticación no están pensados para un app móvil que puede saltar de conexión WIFI a 4G en medio de una sesión.

¿Y si no queremos hacer una app, sino varias, tal vez decenas?

Las apps tienden a crecer e incorporar nuevas funcionalidades hasta que dejan de funcionar en los dispositivos más antiguos. Por ello, cada vez más empresas dividen sus apps por funcionalidades, o sacan una versión Lite para mercados menos desarrollados.

También es posible que queramos sacar variaciones de nuestra app dependiendo de particularidades geográficas que vayan más allá de una localización del lenguaje. Las empresas tienen diferentes modelos de negocio en los diferentes países.

Quizás necesitamos un kit de herramientas para uso interno por los distintos trabajadores de la empresa. Cada app tendrá funcionalidades diferentes, algunas compartidas y todas en base a la información corporativa.

¿Qué ocurre cuando los datos corporativos están detrás de una VPN? No será fácil acceder a ellos.

Al final podemos encontrarnos con decenas de clientes API similares pero no iguales, repetidos en diferentes lenguajes, accesos a bases de datos corporativas mediante librerías o drivers para cada plataforma o incluso web crawlers donde no podamos acceder a los datos de otra forma.

Finalmente, está el problema de la distribución de estas apps cuando son para uso exclusivamente corporativo: no queremos subirlas a las stores de Apple o Android. Tenemos que proporcionar un sistema de firmas de apps que puedan utilizar muchos desarrolladores sin generar agujeros de seguridad… ¡No queremos rogue apps entrando a nuestros servidores!

RHMAP al rescate

RHMAP es un mBaaS que nos proporciona muchas soluciones a los problemas que he comentado más arriba. Algunas de esas soluciones son: autenticación, sincronización de datos, Push notifications, analíticas o almacenamiento en la nube.

Pero RHMAP es más que un mBaaS, es un Mobile App Platform (de ahí el MAP, el RH es de Red Hat), que gestiona e integra todos los aspectos de nuestra app. Añade facilidades para el desarrollo, integración continua, microservicios, cloud apps y varias otras funciones que veremos brevemente.

Red Hat adquiere el mBaaS FeedHenry en octubre de 2014 y desde entonces ha añadido muchas funcionalidades sobre él a la vez que ha ido mejorando las que ya existían. Algunas de estas características son open source y otras están en camino de serlo en los próximos meses.

• Conectores y servicios Node.js para su integración con los sistemas empresariales.
• Aplicación cloud Node.js para el acceso a estos conectores desde el sdk de las aplicaciones.
• Push notifications unificadas mediante Aerogear, otro proyecto Red Hat.
• Integración con OpenShift: RHMAP está inicialmente desplegado en servidores AWS, pero gracias a OpenShift admite despliegue on-premise o en otros proveedores.
• Granja de aplicaciones: las app se pueden compilar y distribuir en la granja de aplicaciones como parte del proceso de integración continua.

Veamos cómo estas y otras características de RHMAP solucionan los retos que comenté anteriormente:

La arquitectura tipo de un proyecto RHMAP se compone de las apps para las diferentes plataformas que se comunican a través de una App cloud con una serie de microservicios.

Para las apps disponemos de SDKs para todas las plataformas tanto nativas como híbridas, incluyendo iOS, Android, Xamarin, etc. Además, también disponemos de aplicaciones especiales como formularios que podemos componer fácilmente en un entorno WYSIWYG y desplegar sin tocar una sola línea de código. También podemos usar los formularios integrados en nuestras apps nativas o híbridas.

La App cloud gestionará toda la lógica de negocio de nuestro proyecto. Escrita en Node.Js tiene soporte de NPM y puede utilizar módulos Node, lo que nos da acceso a cientos de miles de funcionalidades ya disponibles.

Usa MongoDB y Redis para almacenamiento y caché, aunque puede utilizar otras bases de datos. Proporciona un Interfaz RESTful para integración con el resto de componentes.

Si en nuestros desarrollos vemos que parte de nuestra lógica de negocio, incluida en esta cloud app, puede ser utilizada en otros proyectos, podemos extraerla a un servicio.

Los servicios también están escritos en Node.js. RHMAP nos proporciona muchos ya construidos como Sendgrid (email), Twillo (SMS), Paypal, Salesforce, Amazon SES y SQS, Google API, MS Sharepoint…

Además podemos escribir nuestros propios servicios para acceder a los sistemas del cliente o a otras API Gateway. La autenticación de estos servicios puede ser independiente, accediendo al interior de las VPN del cliente de manera segura.

El desarrollo se puede hacer vía web utilizando la consola de la plataforma que nos proporciona un IDE básico o, de manera mucho más práctica, en local. Podemos utilizar nuestras propias herramientas para escribir el código, Android Studio y Xcode para las Apps nativas, Atom, VS Code, o nuestro editor de texto favorito para Node.js y Javascript...

También podemos usar MongoDB y Redis localmente para la app cloud que corre en nuestro PC mediante Grunt durante el desarrollo y luego dejar que Jenkins se encargue de pasar los tests, subir el código a los repos de RHMAP y desplegar las apps, en entornos de desarrollo o producción y stores públicas o privadas.

MBaaS y arquitecturas empresariales

En este caso, y como se puede apreciar en el este gŕafico, el MBaaS se encarga de hacer de proxy entre los clientes del canal móvil y estos servicios, incorporando las funcionalidades descritas en este post a la arquitectura empresarial para dispositivos móviles.

Tras trabajar con varias herramientas MBaaS, desde Paradigma entendemos el uso de este tipo de soluciones dentro del marco de una arquitectura empresarial en la que hay unos servicios bien diseñados e implementados para soportar omnicanalidad son los protagonistas.

Estas soluciones no deberían sustituir una arquitectura empresarial, sino complementarla con funcionalidades para dispositivos móviles como las que he descrito en el post.