What is the performance cost of an onSnapshot in firestore?

Question

I am designing an app that contains (a lot of) documents which are shared to (possibly many) groups.

I need to understand how document changes are pushed from the server to the client in order to build my data model.

1. Are all changes to the database pushed to the clients (with minimal data) and clients download what has been registered with onSnapshot ?
2. Is there a filter on the remote server that is updated and only relevant data is pushed to the client ?

In model (1), the cost of adding many onSnapshot (one for every document) seems low. In model (2), it could be high but it is a burden on the server ? How does all this relate to firestore pricing model (Read counts).

Thanks for any lights on this...

Answer 1

Actually, the answer is in the code:

/**
 * A PersistentStream that implements the Listen RPC.
 *
 * Once the Listen stream has called the openHandler, any number of listen and
 * unlisten calls calls can be sent to control what changes will be sent from
 * the server for ListenResponses.
 */
export class PersistentListenStream extends PersistentStream< // ...

When we create an onSnapshot, the query is sent to the server which remembers what the client is interested in and updates it's notification filter.

This means that we are in scenario #2 and it explains the cost of open connections for the server.

This also means that we do not care how many onSnapshot we create. Concerning the client, there is no performance issue in doing one onSnapshot for each document we get (but there is a Read cost in Firestore for this).