Se state creando un’app e vi state apprestando a sviluppare la parte server, fermatevi un attimo e leggete quest’articolo: farà sicuramente al caso vostro e potrebbe farvi risparmiare qualche settimana di lavoro!
Perche’ un’app ha bisogno di un server?
Se a questa domanda diamo per scontata la risposta: “salvare dati e condividerli”, ci sono altri risvolti che spesso non vengono presi in considerazione. Vi faccio un esempio: pensate a un gioco che ha delle regole. Queste regole molto probabilmente sono configurabili: numero di turni nella partita, parametri dell’intelligenza artificiale, livelli di gioco e così via.
Pensate a questo scenario: il vostro gioco è molto scaricato ma dall’analytics scoprite che dopo 3 partite il gioco viene cancellato. Tutti si fermano allo stesso livello. Forse troppo difficile?
Per validare questa ipotesi andate sul vostro server e abbassate la difficoltà del gioco: cambiate alcuni parametri e salvate. Dopo un giorno, le vostre statistiche iniziano a migliorare notevolmente e iniziate a guadagnare con i crediti acquistati come in-app purchase!
Questo è un esempio reale, che ha riguardato un gioco effettivamente esistente, realizzato da MakeItapp: Football Seasons [1]. Non è stato necessario ripubblicare ogni volta l’app nello store, e il tuning è stato fatto man mano che il gioco veniva usato: tutto questo grazie al Backend as a Service (BaaS).
Introduzione al BaaS
Un’app non è sempre semplice e veloce da realizzare. Dietro la semplicità spesso si nasconde una User Experience ben studiata, un design pulito e un codice ben realizzato. Ma non basta. Le app hanno molto spesso bisogno di servizi lato server. I servizi più noti e utili sono:
- salvataggio di dati per la condivisione con altri utenti e device;
- upload e condivisione di files, immagini e video;
- autenticazione e autorizzazione degli utenti;
- invio di notifiche push.
A fianco di questi servizi, possiamo aver bisogno di validare gli acquisti fatti con l’app, gestire i banner pubblicitari o conoscere il comportamento dei nostri utenti attraverso analytics che garantiscano la privacy…
Questi servizi server si prestano molto bene a essere standardizzati e riutilizzati: quindi perche’ rifarli, installarli e configurarli ogni volta?
Il concetto di servizio
Il concetto di servizio è stato sempre un aspetto fondamentale nelle architetture enterprise ma spesso di difficile implementazione e fruizione da parte dei client. I servizi cloud hanno semplificato questi aspetti e li hanno disaccoppiati fortemente dalle tecnologie. Le interfacce RESTful sono ora uno standard per chi vuole costruire piattaforme fruibili in modo semplice.
Unendo tutti questi aspetti, sono nati nel 2011 i Backend as a Service (o Mobile BaaS o semplicemente BaaS), servizi cloud che nascondono tutti gli aspetti “ripetitivi” dei server quali l’accesso ai dati o l’autenticazione e offrono API semplici e accessibili alle app senza doversi preoccupare di server, configurazioni e implementazioni che spesso sono uguali per tutte le app.
Servizi di un BaaS
Un Backend as a Service raggruppa sotto un unico cappello:
- API per la gestione dei dati;
- servizi per le app mobile;
- SDK client (iOS, Android, Windows, JavaScript) per accedere semplicemente a questi servizi;
- una comoda dashboard per gestire API e servizi;
- un data entry a supporto delle attività di backoffice.
Tipicamente un BaaS espone le API e i servizi come API RESTful, semplificando di molto l’integrazione con diverse piattaforme e linguaggi. Rispetto ai Web Service SOAP, infatti, non è necessario definire i tipi dato con il WSDL con il conseguente rischio che, con alcuni linguaggi, il marshalling dei tipi di dato complessi non funzioni.
Figura 1 – Architettura tipica di un BaaS.
I vantaggi del BaaS
Un BaaS punta alla semplicità delegando molta della complessità e della logica di business alla app. Sopra un BaaS si possono costruire servizi complessi lato server, ma tipicamente questi servizi non servono per un’app. Il consiglio è di disaccoppiare le API per la app mobile e l’eventuale logica di business enterprise integrandola con un Gateway/Service Bus.
Un esempio di architettura è quella di parse.com su Amazon AWS [2]. La semplicità risulta evidente. Si punta su un servizio potente e scalabile che costi in relazione all’effettivo utilizzo del servizio. Infatti un’app potrebbe avere pochi utenti al giorno come decine di utenti al minuto.
Figura 2 – Un esempio: parse.com su Amazon AWS.
Vediamo di seguito una analisi più estesa dei diversi servizi appena menzionati.
Collezioni dati
Il servizio principale di un BaaS è la gestione delle collezioni dati. Con “collezione” si intende un’entità che possa essere elaborata CRUD:
- creata inserendo un dato (Create);
- letta con filtri, paginazione e ordinamento (Read);
- aggiornata con nuovi campi (Update);
- rimossa (Delete).
Queste operazioni sono tipiche di tantissime applicazioni e vengono affrontate sempre allo stesso modo. Con un BaaS la gestione si semplifica notevolmente.
Infatti un BaaS offre la possibilità di definire la collezione attraverso la dashboard oppure direttamente inserendo la prima collezione JSON con un POST sul server.
Figura 3 – Definizione di una collezione attraverso il dashboard di un BaaS.
L’SDK sincronizza in modo trasparente le collezioni sul device e sul server eliminando il problema del sync per le app quando sono offline. Basta chiamare il metodo save della libreria mobile offerta dal BaaS e tutto il resto è delegato all’SDK.
Figura 4 – Risultato della GET di una collezione gestita da un BaaS.
Basta quindi ai fiumi e fiumi di SQL sempre uguali, e basta con complessi ORM; basta setup di database, connection pools e drivers. Con pochi click e una linea di codice abbiamo un “database generico” al servizio della nostra app.
Come ulteriore funzionalità, è possibile impostare eventi che scattano all’inserimento, aggiornamento o rimozione di un elemento di una collezione. Questi eventi tipicamente sono “scriptabili” e attraverso gli script è possibile aggiornare altre collezioni o richiamare altri servizi del BaaS.
Files
Un altro tipico bisogno delle app è salvare files, tipicamente immagini e video. Uno spazio per i files protetto, di dimensioni adeguate e veloce ha un suo costo ed è uno di quei tipici servizi che scalano. Non ha senso prevedere 100 GB di spazio per la nostra app già dal primo giorno. Ma sarebbe meglio che crescesse man mano che cresce il numero di utenti dell’app.
Il servizio offerto dal BaaS permette di scalare la dimensione dello spazio necessario con il crescere della app offrendo sempre tempi di risposta adeguati.
Figura 5 – Esempio di upload di una directory con CURL, richiamando il servizio BaaS “files” di MakeItapp.eu.
In questo modo, con poche linee di codice, la app mobile ha un filesystem di dimensioni virtualmente infinite; a dir la verità, nell’esempio sopra, sono 256 TeraBytes…
Push notifications
L’invio di notifiche agli utenti di un’app quando l’app non è attiva avviene attraverso le push notifications.
Le push notifications non sono inviate direttamente dal server BaaS alla app, ma devono passare per forza dal server del vendor del sistema operativo dello smartphone. Questo perche’ il sistema operativo è costantemente collegato con il server di notifiche del vendor anche quando la nostra app è spenta.
Per cui, se una app è multi-device, è necessario implementare diverse modalità di invio notifiche, uno per ogni vendor (Apple, Google, Microsoft e così via).
Un BaaS nasconde tutta questa complessità. Semplicemente dovrete registrare il device sul BaaS e poi richiamare un servizio REST dicendogli messaggio e ID del dispositivo; a tutto il resto penserà il vostro Backend as a Service.
Autenticazione, autorizzazione e social
L’identificazione dell’utente di un’app è fondamentale quando si vuole offrire un servizio personalizzato o proteggere i suoi dati dagli altri utenti. Quante volte avete implementato la classica login con username e password?
Con un BaaS la trovate già pronta per essere utilizzata. Inoltre tutta la gestione di backoffice degli utenti è garantita dalla dashboard.
Figura 6 – Dashboard di gestione utenti.
Alcuni BaaS iniziano a offrire i servizi di login social con OAuth e OpenId rendendo trasparente tutto il meccanismo. È sufficiente impostare le chiavi dei servizi di autenticazione dei rispettivi social e tutto il resto è garantito dal server e dal client SDK. Questo è molto utile per rendere ancora più accessibile e virale la nostra app.
Una volta identificato l’utente è importante anche definire cosa l’utente dell’app può fare e/o vedere. L’autorizzazione è un tema complesso che tipicamente i BaaS affrontano ponendo limiti di lettura, scrittura e cancellazione a tutta una collezione o a un singolo elemento della collezione.
Analytics
Per migliorare la vostra app e renderla sempre più utile è fondamentale capire il comportamento degli utenti. Un mobile analytics ha questo scopo: raccoglie le informazioni legate alle sessioni utente e le mette a disposizione del team che lavora alla app per migliorarla. Legando la profilazione utente all’analytics il BaaS è in grado di indirizzare al meglio la pubblicità.
Figura 7 – Esempio di Analytics offerto da makeitapp.eu.
Abbiamo visto fin qui i servizi base di un BaaS, ma non si tratta dagli unici servizi disponibili: vediamo di seguito i servizi avanzati disponibili.
Servizi avanzati
Oltre ai servizi base, molte altre API possono essere esposte dal vostro server in cloud per agevolare la vita alla app. Vediamone ancora alcune.
Validazione dell’in-app purchase
L’acquisto in-app è uno dei modi più efficaci per guadagnare. Il modello di business “freemium” sta dando maggior guadagni rispetto sia a quello esclusivamente a pagamento che a a quello gratuito con pubblicità.
Ma se i vostri utenti trovano il modo di truffarvi evitando di pagarvi? Chiedete come sia possibile? Facendo finta di essere Apple o Google! È un attacco tipico di middle-man. L’utente imposta sulla sua connessione wi-fi un proxy che intercetta la chiamata allo store e restituisce sempre OK, grazie anche a delle ricevute valide che girano in rete.
Per evitare la truffa, è necessario far validare l’acquisto non dalla app stessa ma da un server che non può essere intercettato. Il server parlerà direttamente con Apple e Google e attiverà l’acquisto solo se la ricevuta è valida. Questo è un altro servizio BaaS semplice e molto molto utile.
Figura 8 – Collaboration diagram di come funziona l’in-app validator del BaaS di MakeITapp.eu.
Crash server
Aprire l’app e vedersela chiudere sotto il naso non è molto piacevole. Però può succedere… Ci sono molti device e molti casi limite che spesso non si riescono a testare se non in produzione. Poter raccogliere i crash dell’app, per poi analizzarli, vi aiuta a correre ai ripari per tempo.
Il BaaS può offrire un servizio che fa al caso vostro, visualizzando gli errori raggruppati per tipologia e lo stack che può essere linkato al codice sorgente una volta che l’abbiate scaricato.
Pubblicità
Quale banner visualizzare e dopo quanto tempo? In che posizione? Chi ha cliccato sul banner ha poi acquistato quel prodotto? Il servizio di advertising offerto da un BaaS può aiutarvi a rispondere a tutte queste domande. Con un BaaS a supporto è possibile infatti sia offrire la vostra pubblicità, che quella di terze parti, unendole in un solo servizio.
BaaS, alcuni link utili
Siamo solo all’inizio del viaggio con i Backend as a Service. Vi invito a scoprire molti altri dettagli e vantaggi provandoli. Ecco alcuni link di alcune piattaforme BaaS
Parse.com
Il più usato con più di centomila app che lo stanno usando in tutto il mondo [3].
Microsoft Azure Mobile Services
La piattaforma di Microsoft è ben fatta e offre anche servizi adeguati per iOS e Android [4].
BaaS Box
Un BaaS che potete scaricare e far girare sul vostro server Java. Vi svincola quindi dai vendor, ma ovviamente richiede la gestione e la manutenzione del server [5].
MakeItapp BaaS
La piattaforma social MakeItApp.eu [6] offre un BaaS ai suoi Talents a supporto delle loro app, senza costi di avvio. In più, rispetto agli altri BaaS, è offerto anche un data entry di backoffice utilizzabile dagli utenti finali che devono gestire i dati della app (ad esempio, possono inserire facilmente news o nuove ricette di cucina per la loro app).
Conclusioni
Abbiamo visto in questo articolo le caratteristiche principali dei Backend as a Service, mettendone in luce l’architettura, i servizi e i vantaggi offerti. Per oggi ci fermiamo qui nella nostra esplorazione dell’ecosistema delle app; nel prossimo articolo, parleremo di marketing per le app.Contattatemi pure su Twitter (@giulioroggero) se avete domande o commenti!
Riferimenti
[1] Il gioco Football Seasons
http://www.footballseasons.eu/
[2] Un esempio di architettura BaaS
http://aws.amazon.com/solutions/case-studies/parse/
[3] Parse.com, il BaaS più utilizzato
[4] Microsoft Azure Mobile Service, fornisce servizi anche per iOS e Android
http://azure.microsoft.com/en-us/develop/mobile/
[5] BaaS Box può funzionare su un server Java personale
[6] MakeItApp è un BaaS con spiccate caratteristiche “social”
http://www.makeitapp.eu/tools-sdks/baas/