Avoid setTimeout in Firestore

[wilhuff]

I've created this issue based on an internal bit of feedback:

Firestore reads are much slower when the tab is not focused.

When the browser tab is not focused, Firestore reads always take over a second. This is likely because a setTimeout is being used in the code and when a tab is unfocused setTimeouts always take 1 second or more to complete, even if they are requested to be milliseconds long.

You should consider using Promise.resolve().then(theDelayedFunction) instead of setTimeout(theDelayedFunction) to allow queuing all operations in a single tick. This will accomplish the same thing without the throttle the browser adds to setTimeouts.

[jacwright]

The title for this issue should read: Don't let browser throttle requests

I am handling my own offline solution. My app stores everything to IndexedDB and just 1 browser tab connects to Firestore and brokers syncing the data from IndexedDB to Firestore. When that tab is not the current tab, the sync slows down a ton. Each call takes 1 second because of the setTimeouts used and browser throttling.

This is only a problem when users are using your app in multiple tabs. So of course, they do this, because they're users.

I've attempted to look at fixing this, but it seems there are setTimeouts outside of the Firestore code that Firestore relies on it seems. Someone who understands the SDK code better may be able to help.

The realtime database doesn't have this issue.

[mikelehen]

@jacwright For what it's worth, I think browsers throttling background tabs is becoming a fact of life (that's good for users and their battery life) and so there's only so much we can or should do to try to circumvent that. This is why our multi-tab persistence implementation makes an effort to have the foreground tab be the "primary" which is doing the bulk of the work.

I'm a little surprised that avoiding setTimeout(..., 0) makes a difference, but I also have no problem with moving away from it.

I've attempted to look at fixing this, but it seems there are setTimeouts outside of the Firestore code that Firestore relies on it seems.

Can you elaborate on that? Did you see something specific that led you to that assertion?

[jacwright]

@mikelehen I agree browsers should throttle background tabs. In this case, we are opting into the throttling by using setTimeout to make calls async.

I replaced the setTimeouts in Firestore, specifically within async_observer.ts, the scheduleEvent method, but I got them all for good measure. The issue still occurs, and I've concluded it must come from the webchannel-wrapper package, which just points to goog.* namespaces. I don't know how to follow it from there.

Does the multi-tab persistence disconnect the database connection from tabs that lose focus and reconnect them on the focused tab? Or does each tab maintain a connection to the database? Is there a way to piggyback off of the solution there with custom code?

Much of my data could use the built-in persistence, but there is some that requires custom logic around merging changes (I am rebasing OT operations against incoming data and bumping their version numbers up).

[mikelehen]

@jacwright Ahh, I see. Yeah, webchannel comes from closure-library which is built by a different team at Google. I can raise this subject with them, but it'll probably take some time.

And yes, we end up disconnecting background tabs and reconnecting from the foreground tab as tabs lose / gain focus. The code responsible is here. The implementation of canActAsPrimary() is where the foreground checks live. Unfortunately it's all internal implementation and there's no way for custom logic to hook into it, so it probably doesn't help you. Sorry!

[jacwright]

Thank you @mikelehen.

In the meantime, I'm going to see about getting clever with the persistence feature to see if I can use it with custom merging.