-
Notifications
You must be signed in to change notification settings - Fork 614
[Firestore] FR: keepSynced - control what gets in the offline cache #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The RealTime Database's keepSynced API essentially just starts a listen with the backend with a no-op callback and no way to stop it. For Firestore we're hoping to implement an alternative query, indexed on update time, that allows a keepSynced API to also be able to perform a fully incremental sync, avoiding repeat charges outside the 30 minute window. Unfortunately, this needs backend support and we're currently avoiding these kinds of changes in our push toward GA. Until we can do this right we don't want to add extra API surface area. In the meantime to emulate the RTDB's current behavior just start a listener at startup. Of course the one major difference between these platforms is that RTDB's queries are deep while Firestore's queries are shallow. This difference is intentional and comes from years of experience with customers accidentally bringing down their database because they didn't realize the volume of data that was being transferred. If there are subcollections within a user that you want to sync, sync them specifically. |
I'm going to leave this open because we are intending to address this, but we're not going to do the trivial API sugar that RTDB did so it's going to be a while before this lands. |
Any update on this? |
@zdnk No updates to announce, sorry. If you're waiting on this, feel free to chime in with your use case so we can keep it in mind as we design this feature in the future. Thanks. |
We have a use case where we want to store some sensitive information on device. As of now we can't use the Firebase offline mechanism as it lacks encryption at rest, but we would still like to use Firebase as the transport mechanism. Our work-around would be to cache n copy of the sensitive data in an encrypted store while being able to persist the non-sensitive data with the normal Firebase mechanism. We would need to ensure that the sensitive data is not included in the unencrypted Firebase cache and this feature request seems to describe a method that would accomplish that. |
@shawnsarwar The best way to handle this is to use two different Firestore instances pointing at the same project. Create e.g. the main one with persistence enabled. Create a second one with a non-default Firebase App and configure it to have persistence disabled. Use the appropriate Firestore instance based on the data type you're using. |
@wilhuff Clever. Thank you! |
Any updates on this? This feature make Firestore to be offline first database in some scenarios |
What feature would you like to see?
Something similar to what the Realtime Database offers:
This should store ALL data that this document reference contains and remove ALL other data from the cache.
How would you use it?
It would be great to limit the amount of data Firestore syncs and control what gets synced (our users experience cache misses when they are offline, frequently). Our team organized the document model so that every user has its own root that we would like to keep in sync.
That way, one can use the Firestore database as an offline-first solution.
The text was updated successfully, but these errors were encountered: