Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

195 maggio
, anno 2014

Mobile apps

III parte: Backend as a Service (BaaS)

Giulio Roggero

Giulio Roggero

Come CTO e co-founder di Mia-Platform, aiuta i team a semplificare la digital transformation delle aziende concretizzando le loro strategie in software funzionante.
Ingegnere Informatico, è anche tra i fondatori di Agile Reloaded srl e ricopre il ruolo di Strategic Partner di Intré srl.

MokaByte

Mobile apps

III parte: Backend as a Service (BaaS)

Giulio Roggero

Giulio Roggero

  • Questo articolo parla di: Hardware & Tecnologia, Internet & Digital, Programmazione & Linguaggi

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

https://parse.com/products

 

[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

http://www.baasbox.com/

 

[6] MakeItApp è un BaaS con spiccate caratteristiche “social”

http://www.makeitapp.eu/tools-sdks/baas/

 

 

 

 

Facebook
Twitter
LinkedIn
Giulio Roggero

Giulio Roggero

Come CTO e co-founder di Mia-Platform, aiuta i team a semplificare la digital transformation delle aziende concretizzando le loro strategie in software funzionante.
Ingegnere Informatico, è anche tra i fondatori di Agile Reloaded srl e ricopre il ruolo di Strategic Partner di Intré srl.

Giulio Roggero

Giulio Roggero

Come CTO e co-founder di Mia-Platform, aiuta i team a semplificare la digital transformation delle aziende concretizzando le loro strategie in software funzionante. Ingegnere Informatico, è anche tra i fondatori di Agile Reloaded srl e ricopre il ruolo di Strategic Partner di Intré srl.
Tutti gli articoli
Nello stesso numero
Loading...

Prototipare con MEAN.io

I parte: Introduzione e panoramica

Guida alla retrospettiva

II parte: Le retrospettive nella letteratura corrente

Speciale CoseNonJaviste

Dagger: dependency injection su Java e Android (I parte)

Guida Galattica per scrummers

VIII parte: Le stime.Che cosa sono, come e quando farle in un progetto agile

Nella stessa serie
Loading...

Mobile Apps

II parte: Trend e tecnologie. Pro e contro delle app native e ibride

Mobile Apps

I parte: Applicazioni mobili, un mercato maturo e in crescita

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte