Approach of fallback to indexedDB when offline

[kushagra gour]

This is about offline persistance mode in Firestore DB. When you go offline and send a read request to Firestore, it attempts to send a few remote read requests, even when they fail, before falling back to the local indexedDB. This means that when you go offline, the read call is actually very slow because of Firestore continuously trying to send remote calls. Though subsequent offline reads seem quick.

My question is why does firebase not fallback to indexedDB immediately by detecting `navigator.onLine` value?

[Michael Lehenbauer]

Thanks for the question / feedback. A few notes:

1. I'm guessing you are talking about using get().  get() is designed to make a best-effort attempt to get up-to-date data, and so it will try to wait for data from the server if the client thinks it is online. You may want to consider using onSnapshot() instead which will always give you any data from IndexedDB immediately, and then fire a subsequent event if/when we get data from the backend.
2. We are planning to add an option to get() that lets you specify that you want to forego the backend and just read from cache. That will give you the option to avoid waiting for the server at all if that's what you want.
3. The client already tracks a notion of whether it thinks it is online or offline (based on whether past requests have failed). This means that if you do a get() and it fails to reach the backend and return data from IndexedDB, the next get() will likely immediately return data from IndexedDB without waiting for a response/error from the backend.
4. In general, knowing whether you are online or offline is very difficult in the real-world. navigator.onLine will only tell us if there is definitely no network available, e.g. if you have disabled wifi so it is impossible for network requests to succeed. If you're just in a tunnel / elevator / whatever, it's likely that navigator.onLine will still indicate that you are online, and so the only way to detect that you're not is to try network requests and wait for them to fail. 
5. On that note, I am interested in including navigator.onLine in our online-state detection, but I'm not sure if it'll make a significant difference for your scenario.  I'd actually expect that in the cases where navigator.onLine is false, then the browser will also fail our network requests immediately and so get() should fall back to IndexedDB almost immediately. Where it's probably more useful is when navigator.onLine goes from false to true, that's a strong signal that it's a good time to retry any outstanding network requests we have waiting (rather than waiting the full period for our exponential backoff to kick in).

Sorry for the long reply with miscellaneous thoughts, but hopefully this helps.

If you have a specific scenario where you're seeing navigator.onLine report false, but the client is still taking a long time for get() to give you data, I'd be interested in more information (what device / browser and what state the network is in).

Thanks,

-Michael

On Fri, Jan 19, 2018 at 11:09 PM, kushagra gour <chinch...@gmail.com> wrote:

This is about offline persistance mode in Firestore DB. When you go offline and send a read request to Firestore, it attempts to send a few remote read requests, even when they fail, before falling back to the local indexedDB. This means that when you go offline, the read call is actually very slow because of Firestore continuously trying to send remote calls. Though subsequent offline reads seem quick.

My question is why does firebase not fallback to indexedDB immediately by detecting `navigator.onLine` value?

--
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/9877d689-54eb-4b16-8574-dc445a353c6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.