Does firestore offline cache use workbox?

[mvsica...@gmail.com]

There is so much good news now that PWAs and Firestore are here. I'm discovering wonderful things from each perspective, yet Firestore does not say a whole lot about what makes it's offline cache tick.

I'm thinking its got to be (or will be) Workbox handling the service-worker based caching for Firestore, does any know?

Just wondering how to go about implementing Workbox for the PWA app shell side of things, while at the same time caching dynamic Firestore queries, which apparently is automatically handled by Firestore if it is enabled?

Right about now it would be great to see an article providing deeper insight into how Firestore uses the service-worker under the hood and then how that same worker might be used to also manage the usual PWA assets.

[Michael Lehenbauer]

Greetings,

Firestore uses IndexedDB to store its offline cache and so it's not directly using a service worker.  Of course you will likely want to use a service worker yourself to cache your own assets, and you can use workbox or other tools however you like and it won't have any interaction with Firestore.

I agree that a full-blown service worker + Firestore offline app example would be useful, but in the meantime holler if you have any questions / issues. 

Hope this helps,

-Michael

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/d6dd0dad-ca0e-486e-8b3d-83a7f5e2cbc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mvsica...@gmail.com]

Wonderful, thanks for your reply, great to know that diff cache systems can get along!

For the Firestore IndexedDB cache, is there a way to guarantee that it will hold everything required if the app is taken offline? For example, I load a apex document that has many sub-sections in other collections. All these sub-section branches are required in order for the apex doc to work. So when the apex doc is loaded all refs it has to sections in other collections are resolved/fetched as well.

Can I know for certain that all the sub-sections required by the apex doc are locally cached? I understand there is a way to tell if a query is being loaded remotely or by cache on a query-by-query basis. Is there also a way to get a report on the whole local cache to know if it indeed has the right aspects offline?

A little more insight on how this works and also how much data the IndexedDB can hold would be very useful.

On Monday, November 6, 2017 at 11:34:02 AM UTC-6, Michael Lehenbauer wrote:

Greetings,

Firestore uses IndexedDB to store its offline cache and so it's not directly using a service worker.  Of course you will likely want to use a service worker yourself to cache your own assets, and you can use workbox or other tools however you like and it won't have any interaction with Firestore.

I agree that a full-blown service worker + Firestore offline app example would be useful, but in the meantime holler if you have any questions / issues. 

Hope this helps,

-Michael

On Sat, Nov 4, 2017 at 8:19 PM, <mvsica...@gmail.com> wrote:

There is so much good news now that PWAs and Firestore are here. I'm discovering wonderful things from each perspective, yet Firestore does not say a whole lot about what makes it's offline cache tick.

I'm thinking its got to be (or will be) Workbox handling the service-worker based caching for Firestore, does any know?

Just wondering how to go about implementing Workbox for the PWA app shell side of things, while at the same time caching dynamic Firestore queries, which apparently is automatically handled by Firestore if it is enabled?

Right about now it would be great to see an article providing deeper insight into how Firestore uses the service-worker under the hood and then how that same worker might be used to also manage the usual PWA assets.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

[Michael Lehenbauer]

Sorry for the slow reply,

But to answer your questions:

1. Currently everything you read via onSnapshot() or get() will end up in the cache, so if you have read the apex document and all the referenced documents at least once, then they'll all be in the cache.
   
2. We are working on adding a "garbage collection" mechanism so that the cache will purge items that haven't been accessed in a long time (i.e. you read the document once a long time ago, but haven't used get() or onSnapshot() to read it again).  This could break #1 in some cases, but the garbage collection threshold would likely be large (and configurable), so this wouldn't even affect most apps.
   
3. We are also likely going to add ways to "pin" data that you want to ensure is kept offline (i.e. not subject to garbage collection) which would let you explicitly keep the apex document(s) and referenced documents available offline.
   

In general we would like to give you control and visibility into the state of the offline cache, but this mostly isn't designed out yet.

Thanks,

-Michael

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/9bda40a5-0885-4211-b0c9-ea221f9d27c4%40googlegroups.com.

[Zoom]

Awesome and thank you for such good news, just what I have desired for a long time!

I'm assuming the locally cached docs will be cached under the same structure that they are contained in remotely. It is so good to only have to invoke edit or query actions and not have to concern myself with local vs remote invocation mechanizms, they both work the same but are likely quicker if the docs are local.

Cheers!

[Aydin Bahojb-Khoshnoudi]

Hey Michael,

any news on the "garbage collection" feature?

We have been running Firestore for over one year and are seeing massive performance issues because of the large cached data set in IndexedDB.