Optimize Document, if it was already fetched from Collection

[Strate]

I want to suggest enhancement, which can be useful to optimize usage of Firestore.

Imagine, you get collection of documents:

const collection = new firestorter.Collection("docs");
await collection.fetch();

and after that, somewhere in your app, you want to get document by id:

const document = new firestorter.Document("docs/docId");

Even if your document was already fetched from firestore, you will fetch it again, and subscribe to updates again. This can lead to non-optimal usage of firestore - you do more reads from db, than neccessary.

I think firestorter can have global map with all loaded document's data, and if developer creates Document, which was already loaded, reuse it.

[IjzerenHein]

I find this somewhat hypothetical. I know for a fact that the Firebase JS SDK has a lot of optimisations and caching, although I don't know the details. Thinking about it, I would preferable see this kind of caching inside the Firebase JS SDK, as it already does some level of caching and it could do that the most efficiently. Alternatively, I could imagine having a separate caching layer/lib for Firestore, that returns objects from cache when possible. From an architectural point of view I would separate this from Firestorter, so it is the easiest to reason about and it can potentially be used for uses without Firestorter. But having said that, it would probably be best if this is done by the Firebase JS SDK. Cheers

[RWOverdijk]

This type of caching is already part of the sdk on ios, android and web. On react native for example you can verify this by disabling network:

firebase.firestore().disableNetwork();

And fetching any of the documents that are part of some you fetched before. You will still get the desired result. Snapshot.metadata will have the from_cache property set to true.

[Strate]

@RWOverdijk how can I verify, that making this:

firestore.doc("path").onSnapshot();
firestore.doc("path").onSnapshot();

will not make 2 requests on backend?

[RWOverdijk]

One of many ways. Enable debug, check your usage in the firebase console, log the metadata...

A single listener, even if there's nothing new remote does seem to register as a read, but that's a different point entirely.

In any case your question should probably be, "how can I verify that this doesn't make two requests in firestore", because that's what's responsible for this.

[Strate]

@RWOverdijk but your original point to "enablePersistence" and check it with "disableNetwork" is totally about different type of cache. I think that native sdk don't have feautre, originally requested in this issue.

[RWOverdijk]

@Strate The native sdks have those features. Unless I'm still not getting the question 😄

[Strate]

@RWOverdijk nvm, I am currently use my own re-implementation of firestoreter with reuse of collection/documents references :)

[RWOverdijk]

@Strate All right. If you ever find a way to measure it do share. I find it hard to see a different way of doing it.