There's a lady who's sure all that glitters is gold And she's buying a stairway to heaven.
Son tiempos convulsos para la sincronización de datos entre aplicaciones. Si seguís al mismo tipo de personas que yo en Twitter habréis visto como el nivel de indignación con iCloud por la sincronización por Core Data ha llegado a niveles casi de disturbios. Este post de los desarrolladores de Yojimbo es un buen resumen. Para echar un poco más de leña al fuego, Brent Simmons escribía Why Developers Shouldn’t Use iCloud Syncing, Even If It Worked unos días después.
Mattt Thompson aprovechó el April Fools´ Day para poner una pizca de humor en el asunto dedicando un NSHipster a iCloud.
La sorpresa llegó cuando el día siguiente aparecieron estos dos tweets casi seguidos:
A estas alturas creo que no hay que presentar a Mattt Thompson, famoso co-creador de AFNetworking, pero igual si que hay que volver a repasar algunas de las cosas que ha estado haciendo en los últimos tiempos, desde que abandono Gowalla para entrar a formar parte del equipo de Heroku como Director del área de Mobile:
- AFNetworking se ha consolidado como el framework de facto para realizar cualquier comunicación con servidores, descarga y subida de ficheros, etc.
- Basándose en AFNetworking ha creado AFIncrementalStore, que junto con el servicio Heroku Mobile permite hacer persistencia de Core Data en servidores de forma correcta... ¿dardo envenenado a iCloud?
Los dos trabajos anteriores son bastante conocidos pero también tienen buena reputación los siguientes:
- Cargo Bay es una pequeña librería para realizar la verificación de las transacciones realizadas por In-App-Purchases.
- Orbiter es otra pequeña librería que facilita el control de los dispositivos vinculados a notificaciones para poder usar servicios push de terceros como Urban Airship o Parse sin tener que instalar los SDK´s correspondientes.
- Rack::PushNotification es un webservice para realizar las notificaciones push desde nuestros propios servidores.
Podríamos seguir y seguir con otras muchas pequeñas y grandes utilidades creadas por Mattt: Postgres.app (una cliente standalone para instalar PostgreSQL en el Mac), Induction.app (un cliente de bases de datos también para Mac),... pero creo que esta es una buena representación.
Aparte de los IaaS, PaaS y los SaaS, últimamente empiezan a sonar mucho los BaaS (Backend as a Service) como Parse, Urban Airship, Apigee, Azure o BackBeam.io (que es un desarrollo español, mañico para más señas). Las ventajas de estos Baas son claras, nos permiten disfrutar de una infraestructura necesaria por la mayoría de las aplicaciones móviles sin tener que desarrollar nada. Normalmente, además, tienen una tarifa de entrada que suele ser gratuita en la mayoría de los casos. Una vez que superas ese consumo gratuito, empiezas a pagar. Si has diseñado un buen plan de negocio para tu aplicación, lo normal es que cuando llegues al punto de tener que pagar por usar el Baas ya tengas bastantes ingresos y por tanto te siga compensando seguir utilizándolo.
Heroku, la empresa donde trabaja Mattt es un Paas (Platform as a Service), lo que ofrece es una plataforma donde es muy sencillo desplegar una aplicación. Es decir, el backend lo desarrollamos nosotros y ellos a cambio nos dan facilidades para el despliegue, garantías de escalabilidad y nos liberan del mantenimiento de las máquinas en sí.
Pero si a Heroku le sumamos los desarrollos que ha estado realizando Mattt: un backend para nuestras bases de datos, un backend para los dispositivos que requieren de notificaciones push, le añadimos un servicio para realizar la validación de los IAP en el servidor y un servicio para generar Passbooks (que empiezan a estar de moda) tenemos casi nuestro propio Parse. Además, no es necesario un SDK para la parte cliente, Mattt ya tiene un montón de librerías que se encargan de esto: AFNetworking, AFIncrementalStore, Cargo Bay, Orbiter,...
Helios no es un sustituto de Parse, Urban Airship, TestFlight, Flurry... todavía, pero tiempo al tiempo.
Con Parse tenemos cubierto prácticamente todo lo que se le puede pedir a un backend: persistencia, cuentas de usuario, notificaciones push, servicios de geolocalización. Urban Airship está especializado en notificaciones push, geolocalización y passbook. Flurry tiene métricas de uso y control de errores. Testflight tiene distribución de betas, control de uso y gestión de errores. Crashlitycs solo gestión de errores. New Relic se mete ahora con monitores de servicios.
Si se nos va la mano, terminamos haciendo una aplicación del tiempo con 17 SDK´s diferentes instalados. La idea de Heroku me parece brillante, yo te pongo el hosting y un backend superpersonalizable. Además te doy clientes modulares para lo que quieras usar. Eres libre de usar tu propio servidor pero que sepas que en Heroku es tan sencillo como escribir "git push heroku master" y cuando llegue el momento de pagar, pagarás. No es oro todo lo que reluce ya que pasamos de depender de una caja negra como Parse a un conjunto de servicios desarrollados por una única empresa pero al menos esos servicios son open source, podemos ver el código cuando queramos y depender solo de nosostros mismos.
Ya os digo que a Helios le queda mucho camino por andar, pero tiene muy buena pinta. Estoy haciendo pruebas con él y quiero ver si es fácil de superar las dos principales carencias que le veo ahora mismo: la gestión de usuarios y las notificaciones push sin recurrir a servicios de terceros. También quiero saber si su uso en Heroku implica directamente coste o si, por el contrario, podemos probarlo de forma gratuita con bastante margen... creo que Helios va a ser un habitual en mis próximos posts... Stay tuned!