Rapidly firing subscriptions question.
We currently are looking to migrate from Firebase to Supabase but our realtime watchers don't easily map over to Supabase subscriptions due to their limitation of only allowing a single filter.
If we switched to a single subscription but that subscription was on a set of data shared by 1 to many users would there be any concerns if it was constantly firing?
Our app is a collaborative text editing tool so as a user writes in a document those changes are stored on the backend in a single table. As you can imagine if many users are all writing at the same time (with some writing on different documents) data could be constantly being written and if a single client listens to all changes the websocket could be firing non-stop. With a good number of those triggers being for data one client might not even care about based on where they are in the UI. That seems like it would not be ideal but due to the one filter limitation on Supabase subscriptions it's kind of our only options. Unless we switch to polling for changed data which has its own set of complexities.
If we switched to a single subscription but that subscription was on a set of data shared by 1 to many users would there be any concerns if it was constantly firing?
Our app is a collaborative text editing tool so as a user writes in a document those changes are stored on the backend in a single table. As you can imagine if many users are all writing at the same time (with some writing on different documents) data could be constantly being written and if a single client listens to all changes the websocket could be firing non-stop. With a good number of those triggers being for data one client might not even care about based on where they are in the UI. That seems like it would not be ideal but due to the one filter limitation on Supabase subscriptions it's kind of our only options. Unless we switch to polling for changed data which has its own set of complexities.
