The realtime database events always send all data the current user has access to.
For instance, say there's a collection tasks and a user is viewing the completed tasks. The JavaScript client will receive new insert, update, and delete for all tasks records, not just a subset.
It would be easier for developers to specify some filter when subscribing to receive database events.
For the above example, the subscriber could sent completed = true somewhere.
I'm still unclear if this change should be handle in core or directly in the client-side library.
Changing this in core would also impact the server-side function that handles database events, and potentially some non database related events.
This need some exploration. Implementing this in the client-side library would not change the backend. The client-side could handle filtering directly in JavaScript, the down-side is that the websocket connection transmit the data, and it's getting discarded, but might not be a huge issue for < 10k concurren users app.
The realtime database events always send all data the current user has access to.
For instance, say there's a collection
tasksand a user is viewing the completed tasks. The JavaScript client will receive new insert, update, and delete for alltasksrecords, not just a subset.It would be easier for developers to specify some filter when subscribing to receive database events.
For the above example, the subscriber could sent
completed = truesomewhere.I'm still unclear if this change should be handle in
coreor directly in the client-side library.Changing this in
corewould also impact the server-side function that handles database events, and potentially some non database related events.This need some exploration. Implementing this in the client-side library would not change the backend. The client-side could handle filtering directly in JavaScript, the down-side is that the websocket connection transmit the data, and it's getting discarded, but might not be a huge issue for < 10k concurren users app.