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:

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:

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

Otras funcionalidades útiles, aunque menos imprescindibles:

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:

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.

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.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.