Yup. Though I've found that any impact on cost is limited (at least compared to enabling Firestore persistence). It's mainly a performance improvement. I also added the ability to configure the HOLD_CACHED_QUERIES_DURATION on a query by query basis. For my app, there are a few queries that make sense to hold for the lifetime of the application since they are used so often.
I've recently jumped back into this code again and it's interesting because in the end it didn't reduce the cost that much. But now I understand something a little bit better. Keeping a query in cache reduces the cost if this query is called several times from several different places or if you do a lot of back and forth in the app. But when you leave a page which needs a query results, you'll still get charged for every update to this query for 3min (or the duration you chose) even if you don't need them anymore. Does that sound right @johncarroll ?
But when you leave a page which needs a query results, you'll still get charged for every update to this query for 3min (or the duration you chose) even if you don't need them anymore. Does that sound right @johncarroll ?
I haven't pushed to prod yet but for what I've tested I'm expecting a huge cost reduction. If not then it means that Firebase already agregates those queries in the SDK. I'm expecting ~70% less reads. (Fyi I'm not using persistence since I had huge performance issues with it).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yup. Though I've found that any impact on cost is limited (at least compared to enabling Firestore persistence). It's mainly a performance improvement. I also added the ability to configure the
HOLD_CACHED_QUERIES_DURATIONon a query by query basis. For my app, there are a few queries that make sense to hold for the lifetime of the application since they are used so often.I've recently jumped back into this code again and it's interesting because in the end it didn't reduce the cost that much. But now I understand something a little bit better. Keeping a query in cache reduces the cost if this query is called several times from several different places or if you do a lot of back and forth in the app. But when you leave a page which needs a query results, you'll still get charged for every update to this query for 3min (or the duration you chose) even if you don't need them anymore. Does that sound right @johncarroll ?
Yes
I haven't pushed to prod yet but for what I've tested I'm expecting a huge cost reduction. If not then it means that Firebase already agregates those queries in the SDK. I'm expecting ~70% less reads. (Fyi I'm not using persistence since I had huge performance issues with it).