Posted in Uncategorized

FR: Resume firestore synchronization after server side render

   September 29, 2020  2 Comments on FR: Resume firestore synchronization after server side render

I would like to be able to resume watching Firestore without it reloading all documents that I already have when using server side rendering.

I image that the flow would work something like this:

  1. Fetch data from Firestore on the server, and use this data to server side render my application
  2. Pass this data on to the client so that it is immediately available when hydrating
  3. Also pass on the resumeToken so that the client knows where to pick up syncing
  4. On the client, use the resumeToken to start watching for changes, immediately getting any changes that occurred between the server side render and the client watch, but not re-downloading everything that didn’t change.

There is a resumeToken of some sort, but I couldn’t find anything regarding it in the documentation, and it doesn’t seem exposed unless by reading from indexeddb targets. So what the Feature Request would involve is adding a way to see this resumeToken (maybe on querySnapshot metadata?) and passing it into the SDK when creating a new query.

Thanks for making firebase, it’s really nice to build apps on.

Full dicussion on github.com

2 thoughts on “FR: Resume firestore synchronization after server side render”

  1. There is indeed a resume_token, but we don’t expose any apis for dealing with it. It might be possible to use the rest/rpc apis directly to do this…?

    Perhaps easier would be to take the approach I suggested in #1551, specifically, add a last_updated_time or similar field to your documents. Then your specified flow would change to be something like:

    1. (unchanged) Fetch data from Firestore on the server, and use this data to server side render my application
    2. (unchanged) Pass this data on to the client so that it is immediately available when hydrating
    3. Also pass on the largest last_updated_time (or let the client calculate that) so that the client knows where to pick up syncing
    4. On the client, use the last_updated_time to start watching for changes, immediately getting any changes that occurred between the server side render and the client watch, but not re-downloading everything that didn’t change. i.e. use the same query, but with an additional parameter of where last_updated_time > max calculated above.

    Would this work?

  2. As @thefliik said on the other issue, this works well except for not getting notified about deleted documents. I’ve solved it by adding a property to deleted documents with “deleted: true” and every hour running a script that hard deletes any deleted documents that haven’t been changed for at least 2 hours. It has the added benefit of being able to undo deletions very easily, but is a bit fiddly.

    It would be nice to have an easier way to handle the deletions, but it’ll have to do.