Reputation: 14435
According to this answer, Firestore references cannot be used for JOIN-like queries, i.e. for retrieving the referencing document and the referenced document in one database round-trip. This can be a performance issue, since network latency costs apply for each database round-trip.
Network latency is only a problem if you are not close to the datacenter, which means that if you do the join server-side, i.e. in the Google datacenter where Firestore runs, then it should not be a problem.
Can we use Firebase Functions to implement this functionality in a generic manner? I'm thinking of a service, implemented in Firebase Functions, which sits between the client and the database. Most queries are just passed to the database (where
, orderBy
, limit
etc. must still be possible), but there should be an additional populate: true
query parameter. If this parameter is present and set to true, then the referenced documents are returned as well.
Maybe it will also be necessary to indicate which documents should be populate
d.
Upvotes: 0
Views: 56
Reputation: 317352
Sure, sounds like you could give it a try. You can still expect to pay for all documents read by whatever queries you use, even if you don't return that many to the client.
If you really have a lot of joins to perform, it's typically better to pre-compute the joins in another collection, and have the client query that instead. Then you have the advantage of the client having a local cache the helps both speed and cost.
But there's nothing stopping you from implementing a function that does this, if that's what you need.
Upvotes: 2