8

My goal is to optimize my app's architecture for cost when using Firebase Cloud Firestore. I understand Cloud Firestore's pricing model is on a per read/write basis. So I'm considering the following pattern for cost optimization purposes. I want to know whether it's "best practice" or an anti-pattern.

The idea is that whenever I create a new document to add to a collection, I will have the user update a second "master document" that contains some subset of the doc content plus the same from many similar docs from many different users.

Then, when I go to fetch the list data, instead of fetching a collection and getting charges for each document read from the collection (many reads), I retrieve only the master document instead (one read).

In code, it would look as follows.

Instead of this: 
db.collection("reviews")
  .get()
  .then(querySnapshot => {
    querySnapshot.forEach(doc => {
      // doc.data() is never undefined for query doc snapshots
      console.log(doc.id, " => ", doc.data());
    });
  })
I do this: 
const docRef = db.collection("reviews").doc("MasterList");

docRef.get().then(doc => {
  if (doc.exists) {
    console.log("Document data:", doc.data());
  } else {
    // doc.data() will be undefined in this case
    console.log("No such document!");
  }
})

Is this a cost-wise best-practice? Or is this an anti-pattern?

Let Me Tink About It
  • 15,156
  • 21
  • 98
  • 207
  • 1
    It's the best-cost effective approach up-to-date, just have to concern about the size limit mentioned by @Alex Mamo. – Angus Oct 02 '18 at 15:47
  • 2
    Thanks, this is exactly the question I have in mind since I work with firestore (1 month)... but i'ts totally an anti-pattern solution and make my code more complex... as @Alex Mamo said, take look at Firebase realtime database. – Damien Romito Oct 12 '19 at 11:20
  • 1
    I came up with a [simple solution](https://stackoverflow.com/a/63673175/5223309) for my clients who are concerned with firestore pricing. It takes advantage of the cloud firestore caching mechanism to benefit any kind of query you want to make. You can have a look. – Shababb Karim Sep 01 '20 at 09:56

1 Answers1

6

Edit: Aug, 27th 2021

I wrote an article on this topic for a better understanding:

The idea of having a "master document" is a good one because you'll be able to make a single write operation even if you change multiple properties within it but there is a problem regarding a constraint, documents have limits. So there are some limits when it comes to how much data you can put into a document. According to the official documentation regarding usage and limits:

Maximum size for a document: 1 MiB (1,048,576 bytes)

As you can see, you are limited to 1 MiB total of data in a single document. When we are talking about storing text, you can store pretty much but as your document getts bigger, be careful about this limitation.

Cloud Firestore is optimized for storing large collections of small documents. So you should take advantage of this feature. Even if you need to duplicate and update several documents within separate collections, I recommend you go ahead in this way.

P.S. If you worry about costs, take also a look at Firebase realtime database and try to use them together. Are working pretty fine.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • 5
    "Cloud Firestore is optimized for storing large collections of small documents." Cloud Firestore works equally well with any collection size, and with any document size within its limits. – Frank van Puffelen Oct 02 '18 at 15:19
  • I came up with a [simple solution](https://stackoverflow.com/a/63673175/5223309) for my clients who are concerned with firestore pricing. It takes advantage of the cloud firestore caching mechanism to benefit any kind of query you want to make. – Shababb Karim Sep 01 '20 at 09:56