Our team is considering moving our firestore application to supabase. However, we currently use the onSnapshot functionality(https://firebase.google.com/docs/firestore/query-data/listen) extensively throughout our application. We use the firebase web-sdk to listen to real time changes on data.. Every time the app boots up, we start up listeners that listen to collections for changes, allowing our app to basically have a real-time sync of data for all users in the web-browser. I know that supabase has a "changes API", but this looks like it isn't exactly what we need, because when a user loads up the browser, they need to have an "initial snapshot" of the data and then start listening to changes from that snapshot going forward. The changes api appears to only give you changes, but not an initial starting snapshot of the data. Is there a way to do this behavior with supabase? I'm happy to explain further if the above explanation is not helpful. Thanks! -Michael

You have to create the "snapshot" table yourself with initial database queries, and then use realtime to get event changes and you keep it updated based on those events. Realtime does not do queries, but gets single row updates from a table with 1 filter of several types shown at the link below. You have to deal with joins either with a database call or with multiple realtime subscriptions. Depending on the complexity of your snapshots this can be somewhat easy to hard. https://supabase.com/docs/guides/realtime/extensions/postgres-changes describes what is available.

how do i create the snapshot and atomically ensure that i get the changes starting from the time of the snapshot?

I do the subscription first, then when it reports connected, I load the initial data in that handler. I've not done multiple subscriptions on a data set before though.

this approach seems rife with potential race conditions no? so you listen to the listener first, and then you load the initial data... so what if the initial data overwrites the events in the listener?

https://supabase.com/docs/guides/realtime/extensions/postgres-changes#combination-changes This example seems to imply you can have multiple tables and a single status to trigger on.

you could have writes occurring on the real time listener... and then you are still "loading" initial data"

The opposite is also true. You can't get the data and then call realtime, that is worse as you could lose seconds of data while it connects. I understand your case. You certainly know all the events coming in, and I need to think thru how replication works between the table you get and then a change before and after your read as to if it is a realistic race or not. It could be. There is no information from Supabase in guides or docs on dealing with this that I know of, and I likely would.

there's really no way to guarantee that the data will be accurate. even if the realtime listener and the snapshot are delivered consistently, once it gets to the application level code, depending on how its processed, a callback might get ordered one before the other, that could lead to data that doesnt look right. the only way to solve this issue is to have some explicit logical ordering so that updates that have been overwritten are explicitly dropped, on both the snapshot loader AND the real time listener

There certainly is nothing built in. And I agree there is a race, unless you can just reload the query each time there is an update, which works for some cases. Also dealing with an event that you have before your initial data has finished loading is possible with a queue, but messy and may need to involve an updated at field...