Le but n’est pas de faire un comparatif entre Realtime Database et Firestore puisque Google l’a déjà fait ici (je vous recommande d’ailleurs de le lire). Mais de le mettre en oeuvre dans une application Android :
Dans mon exemple je vais afficher un spinner contenant la liste de nos agences (Lyon / Nantes), rien d’extravagant.
Et une RecyclerView pour afficher la liste de nos experts et de leurs références, filtrée en fonction du choix d’agence. Ainsi que la possibilité de leur montrer un peu d’amour en leur donnant un pouce, la chance !
Pour cela je vais utiliser 3 collections, “locations” contiendra les agences qui serviront de filtres et “resources” les données sur nos experts ainsi que les “likes”.
Côté client Android on commence par ajouter le SDK Firestore dans le build.gradle :
implementation ‘com.google.firebase:firebase-firestore:11.6.2’
Puis on recupère l’instance de la base de données via un singleton :
FirebaseFirestore db = FirebaseFirestore.getInstance();
De mon côté j’ai besoin de la liste de nos experts. Ceux-ci sont stockés dans la collection “resources”.
Par défaut cela me donne une erreur car aucune donnée n’est accessible sans authentification.
PERMISSION_DENIED: Missing or insufficient permissions.
Il faut donc modifier les règles de sécurité pour autoriser la lecture des agences et des collaborateurs, ainsi que l’écriture des likes.
Je veux également pouvoir ajouter un pouce à un profil. D’un point de vue technique cela englobe 3 aspects :
La dernière fois j’avais pas des masses de mesures de mes perfs, ce coup ci j’ai fait bosser Firebase Test Lab, malin le gars !
C’est pas pire ! Deux tendances se dessinent, autour de 1s lorsque la donnée doit être fetchée. Mais lorsque la data est disponible offline on est plutôt dans les 0,2 à 0,3s. Ce qui est acceptable de mon point de vue sachant qu’on a pas codé de backend ni de système de BDD / cache côté mobile. À noter que la persistence offline est activée par défaut.
Par défaut Firestore expose également les données via une API Rest :
Pour l’utiliser il faut passer par la console GCloud et générer une Api Key, plus de détail ici.
Exemple d’accès à la collection “resources” ordonnée par “name” en lecture :
HTTP GET https://firestore.googleapis.com/v1beta1/projects/pot-pourri-android/databases/(default)/documents/resources?orderBy=name&key=API_KEY
le (default) nous laisse présager que Firestore pourra être multi BDD comme c’est le cas pour Realtime Database.
J’ai été étonné de constater que l’API renvoyait des attributs “createTime” et “updateTime” qui ne sont pas accessibles via les SDK Natifs… !
Les "yeah" :
Les "hooo..." :
De mon point de vue c’est un outil idéal pour un développeur front qui n’a pas envie / le temps de monter en compétence sur la partie backend. Firestore ne révolutionne rien mais apporte la puissance du NoSQL dans vos applications mobiles sans le moindre effort et rien que pour ça on valide 🙂
À suivre de près donc !
Dans l'épisode précédent...
Petit (re) tour des Bétas Firebase
Raphaël 14 novembre 2017
Si comme moi vous avez bavé devant le Firebase Dev Summit 2017 mais que vous n’avez pas eu le temps de tester les nouveautés, voici un bref aperçu en image des dernières Béta de la suite d’outils mobile de Google, j’ai nommé Firebase.