Tricks to prevent browser listener timeout with Firestore causing excess reads

user_13590970 0
Viewed 412

I have users of my Flutter Firestore app and web site who monitor attendance of their schools and facilities. They typically will have their browsers open the entire day.

Because they manage the entire school, and because students are coming and going for different sessions, they monitor attendance throughout the day. I don't want to limit their functionality with pagination and need live snapshot listeners. I also cannot use cache, as I need realtime data, so I have cache completely turned off on my app and web site with Firestore. The data is minimal, the volume of documents is somewhat high, so reads cumulatively are excessive.

This is mainly because every 30 minutes, Firestore renews the listeners and these admins are running 500 plus reads, doing nothing every 30 minutes....24 hours a day if they leave their computers on. No, I can't ask customers to change behaviors.

So I'm looking for a trick. Is there a way to tweak this to either:

  1. keep the listener live without doing a full collection re-read.
  2. At minimum, extend the time or eliminate the timeout entirely so we don't re-read.
  3. I could I suppose do a timeout window that asks the user to refresh when they come back...however, I haven't found any flutterfire or firebase documentation on how to suspend the listeners (I do not want to mess with their authentication at all).

Based on everything I've seen, Firestore has this 30 minute, set in stone refresh. You can either log the user out entirely or live with it. That can't be the case, right? Any ideas?

google-cloud-firestore flutter
2 Answers

-> Detect inactivity somehow (maybe just a timer > 5minutes on a page => user is inactive)

-> If the user is inactive, detach the listener so it stops loading data.

-> Show a button in the UI like "update" or "". When the user clicks on that button, run the query again to update the data.

A couple of notes:

  • Loading 500 documents at once seems to be excessive. You may want to only show relevant documents, like "students who didn't show up". But this really depends on your specific case.

  • Turning off cache completely, means that you're probably messing with how Firestore caches data to avoid making extra requests to the DB. When making real-time calls, Firestore only charges you for documents that have seen a change (except for the first DB call). The cache is part of Firestore's real-time functionality. So this is just something to keep in mind.

user_62778620

Use a framework like Redux as an intermediary - Listeners send data to Redux; components subscribe to Redux. This helps to decouple the UI from the Firestore backend. My app potentially has 1000's of records available to the user, but only those in view are active at most points. It is also possible (but I haven't written it yet) to Paginate through a Redux store at a finer scale (so you can "Page Back" easily), but page through Firestore on larger pages, less frequently.

I also have to question why you need 500 reads "live" - unlikely any user is actually looking at 500 records at the same time.

user_24347840
Related