FR: Resume firestore synchronization after server side render

[Maistho]

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.

[jorroll]

I would also appreciate this feature.

Related request #1551 (the ability to only subscribe to doc/collection changes, without first downloading the doc/collection).

[rsgowman]

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?

[jorroll]

For my use case, I think your suggestion solves this issue 👍.

Though I won't speak for the OP or weigh in on whether it will work in a more traditional app setup.

[Maistho]

@rsgowman That's actually a pretty neat solution! I should've thought of that myself. 🙂

I think this might a better solution than exposing the resumeToken. I'm going to try implementing it in my app and see how well it works.

[Maistho]

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.