Optimisations Firebase, moins cher et plus performant
Tags: firebase, finops
Published: 2021-01-18 16:24:40

Créé en 2011 et racheté par Alphabet (Google) en 2014, [Firebase](http://firebase.google.com) se présente aujourd'hui comme une solution Backend as a Service très complète et performante. Son approche temps réel permet des applications très réactives et vivantes sans investissement sur le développement d'une solution backend.

Malgré cela, vous avez déjà peut-être hésité à l'utiliser, parce que le pricing n'était pas des plus clairs et peut être aussi parce que vous avez pu voir les fameuses firebase horror stories, comme celle-ci: https://hackernoon.com/how-we-spent-30k-usd-in-firebase-in-less-than-72-hours-307490bd24d (TL;DR: une entreprise a payé 30k€ à cause d’une mauvaise utilisation de firebase qui lui a créé une situation où la facturation grossissait de manière exponentielle)

Comme toutes les solutions cloud, une mauvaise utilisation peut conduire à de mauvaises surprises côté facturation, comme le démontre l'article ci-dessus. Nous allons voir ici comment éviter ces pièges en comprenant comment Firebase fonctionne, et comment il vous facture.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/7yuu18hbrmrlcwz935s8.png)

# Realtime Database

[Realtime Database](https://firebase.google.com/docs/database), c'est *la* fonctionnalité de base de Firebase : une base de données sous forme d'un JSON géant dans lequel vous pouvez piocher et observer.

## Le pricing

Dans Realtime Database, vous êtes facturés au Go transféré, ce qui en fait une base idéale pour stocker des petites données qui changent beaucoup, des indicateurs, des compteurs.

## Ce qui peut mal tourner

Du fait que Realtime Database facture au Go transféré et qu'il propose du temps réel, si vous avez une donnée qui grossi de façon linéaire avec le nombre de vos utilisateurs, alors vous avez un pricing exponentiel. En effet, chaque nouvel utilisateur engendre un listener de plus, et fait grossir la donnée, ce qui envoie la modification aux autres utilisateurs.

C'est comme ça que #UnaVacaPorDeLaCalle a vu son pricing exploser.

## Comment éviter ça?

Si vous avez de gros documents, préférez Firestore, et ne faites jamais une récupération d'un tableau complet pour avoir sa longueur, préférez une [Cloud Function](https://firebase.google.com/docs/database/extend-with-functions) qui ira mettre à jour un compteur à la place, que vous pourrez récupérer facilement.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6joqc1to9r4h68g2k72r.png)

# Firestore

[Cloud Firestore](https://firebase.google.com/docs/firestore), c'est une base de données NoSQL documents en temps réel. Sortie de beta il y a maintenant un an environ, elle est actuellement disponible dans la suite firebase.

## Le pricing

Firestore vous fait payer [par opération sur un document](https://firebase.google.com/docs/firestore/pricing), et non sur le volume transféré, ce qui ouvre les possibilités pour des volumes de données plus importants.

### Les limitations

Même si Firestore est plus intéressant pour les gros volumes de données, il faut garder à l'esprit qu'il a des limites que vous ne pouvez pas modifier:

 - Max. 1 opération par seconde par document.
 - Max. 1MB par document.

Ce sont les deux plus importantes pour le pricing, 

## Ce qui peut mal tourner, ou pas

Firestore est beaucoup moins sujet à des explosions de prix, de par son pricing par opération et le fait que récupérer une collection ne vous coûte qu'une opération au total et non une opération par document.

Cependant, il est important de savoir ce qui coûte des opérations, surtout dans les règles, qui peuvent récupérer un document au prix d'une opération.

## Comment optimiser?

Dans Firestore, l'idée derrière l'optimisation est de réduire le nombre d'opérations de lecture que vous allez faire. Un design idéal veut donc que vous ayez un document qui contient tout ce dont un utilisateur a besoin. Cependant, cela reste à la merci de la limite de l'opération par seconde par document, et donc rend chaque "document utilisateur" modifiable uniquement une fois par seconde.

Même si vous ne pouvez pas atteindre cet idéal, avoir moins d'opérations de lecture obligatoires (au lancement de votre application, sans interaction utilisateur) est la priorité et peut fortement impacter votre pricing Firestore.

# Conclusion

En conclusion, pensez toujours à l'utilisation de vous allez faire d'une des bases de Firebase et pensez toujours aux anti patterns qui peuvent vous coûter cher afin de les éviter, utilisez les cloud fonctions avec les events de base de données afin de faire des opérations de type count.

Vous êtes intéressé•e par Firebase et vous voudriez en apprendre plus ? N'hésitez pas à [nous contacter](mailto:training@zenika.com) pour une [formation](https://training.zenika.com/fr-fr/training/firebase/description).