Aller au contenu
Enter

Firebase | Cloud Firestore & Android

Par :
Youness
-
Développeur FullStack
-
Publié le :
25.1.18

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 :

CONTEXTE

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”.

Exemple de données

Implémentation

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 :

  • Afficher le nombre de likes reçus (en live)
  • Savoir si j’ai déjà liké un profil ou non
  • Ajouter un like sur un profil

Monitoring

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 !

Temps constatés sur 204 appels à Firestore

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" :

  • La structuration des données et le système de query simplifié par rapport à Firebase Realtime Database
  • La facilité de configuration
  • Les nouveaux types d’objets supportés (timestamp même si on regrette qu’il n’y ait pas une option pour les générer automatiquement à l’écriture d’une donnée par exemple, geopoint, reference, array)
  • La sécurisation de l’API Rest de Firestore. Celle-ci est protégé et nécessite la création d’une clé d’API dans la console Google avec la possibilité d’ajouter des restrictions sur la provenance des appels. C’est quand même plus secure que d’ajouter .json à la fin de l’URL de la bdd comme c’était le cas avant…
  • Firebase vous aide à générer vos index, la fonction indexation automatique est d’ailleurs automatiquement activée. La CLI firebase permet d’ailleurs de gérer vos index et ainsi de les versionner pour éviter la saisie manuelle.

Les "hooo..." :

  • En ajoutant des objet de type Reference on s’attendait à ce que Firebase pousse l’intégration un peu plus loin. Impossible de récupérer le snapshot directement, on est obligé de lancer une seconde requête. Impossible de baser nos querys sur les propriétés de la Reference ni d’une sous-collection.
  • Outre les aspects techniques : j’utilisais pas mal la console de Firebase pour l’aspect Back office qui peut permettre de faire de la saisie de données sans avoir à développer une page web ou un écran mobile pour ça, pour les POC c’est pratique. Avec Firestore vous pouvez oublier cet usage même avec 3 éléments dans votre bdd c’est très vite chiant de manipuler les données que ce soit en lecture, en saisie ou simplement pour naviguer entre les noeuds. Et il reste des bugs graphiques lors de la navigation.
  • De la même manière il était simple de “backuper” ses données avec l’ancienne version étant donné que c’était un simple fichier plat. Je me servait d’ailleurs de Firebase Storage pour les backups manuels puisque les backups automatisés ne sont disponibles que dans la version payante et que je suis pauvre / radin… Avec Firestore aucun moyen officiel n’existe pour cela, même si quelques gars fournissent des packages NPMs qui passent directement par Google Cloud. Mais bon on s’en fout on code sans bugs donc ça peut pas nous arriver de perdre des données… !
  • Impossible d’effectuer un count directement depuis les SDKs, ce qui veut dire qu’il est impossible de trier les entrées par nombre de likes dans mon cas. Dans ce cas obligé d’écrire une Function qui va calculer la somme et la stocker dans un champ du document… Pas très pratique quand même !
  • Attention pour ceux qui utilisent Firebase Functions pour faire des traitements sur leur base de données. Ces produits sont tous les deux en béta donc il y a encore des limitations pour l’instant. Le déclenchement du trigger depuis Firestore n’est pas garanti ! De même il est possible que celui-ci soit reçu plusieurs fois pour la même opération. L’ordre d’apparition des events n’est pas garanti et le temps de déclenchement peut monter jusqu’à jusqu’à 5 sec. Attention donc à ce que vous voulez en faire.
  • Pas encore de graphiques d’utilisation des ressources GCloud, j’espère que ça viendra.

Mon ressenti

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.


À lire aussi

Veille digitale, regard d’experts et retours d’expérience