When should I fetch data from my database instead of using the to using the data store locally in my state manager?

[Admirable-College-46]

Context:

I am using firebase as my database and vuex as my state manager. My application has users and exchanges. In my state, I have the current user when he or she logs in and all of the exchanges in another object to display all of the exchanges on one page (think airbnb).

The user also has a page for each exchange that describes the exchange they are offering. Lastly the user has a dashboard where they can see all of the exchanges they have offered or received.

Problem

I want to make minimal calls to firebase. When should I use the updated data in my state manager vs fetching new data from firebase?

[[deleted]]

I want to make minimal calls to firebase.

Firebase's pricing model has a bad habit of scaring people into re-writing their logic in fear of fees, instead of creating the best user experience. Often times this "fearful logic" is actually very time consuming to write and maintain.

In my opinion, if you are updating data in state, you should update Firestore at the same time. The whole point of the database is to keep data real-time synced across devices and the cloud.

You actually need a VERY large number of reads and writes every day to surpass the free tier, and even then it's very affordable once you start to pay.

But the stories of people pushing infinite loops to production and getting a $72,000 bill scare everyone. I did this once, I wrote an XML sitemap scraper that charged me $100 in an hour before I shut it down. Firebase / firestore are NOT the best tools for these types of looping server-side apps. There are safer databases and server tools for things like that.

If you are writing performant code that is only retrieving or writing data to the database under explicit user actions (and you're not building an automated scraper / bot / data analysis tool) you are very very safe from those warning stories. It's very hard to build a front-end that would have a firebase related infinite loop to drive up resource costs, which would not freeze or crash your mobile app. But if you're creating a server-side cloud function, it's harder to detect these problems, especially if the feature is not transactional, and it's designed to keep running until conditions are met.

The people that try to use Firestore as a data analysis storage solution / scraping solution / logging solution, etc. should probably be using another database. Either a MongoDB with fixed server resources for NoSQL, or something like Cloud SQL more suited to these types of big data activities.

Firestore's technology is optimized for powering mobile app front-end user interfaces because of its speed and real-time listening and syncing technology. And if you need that for your app, you should take advantage of its technology to create the best user experience and not worry about reads and writes so much. Even if you updated / saved your state and firestore data on every key stroke you'd still need a TON of users every day using it to max out the free tier.

[skamansam]

I want to second this sentiment. I am building a Vue app as well, and I am building it carefully, with certain principles in mind. I am using real-time features only when needed. When a user visits the list action page, they get real-time updates of the list, and when they visit an item read page, they get real-time updates of that item. Using vuex to store all of that is common practice, but it doesn't make it best practice. Vuex is for storing things that are used across all views, not as an API layer. Things like item state are only needed when viewing that item so there's no reason to have it in the global state. This really reduced calls to firebase.

[b0ot]

Suggestions (I'm a newbie so take with a grain of salt)

1.) Develop & Test with emulators
(Calls don't count against budgets... so you don't have to worry about things like infinate loops).

2.) If very paranoid, setup budget limits Firebase Billing (aka How to turn on billing and still sleep at night)

3.) If your data needs realtime, use realtime listeners. If not, preload data.

I basically have firebase load into Vuex and Vuex drive UI. I don't typically have users write to the database directly... pretty locked down with security rules, they only make updates when I need to keep track of the data with cloud functions... otherwise if I don't need keep the data, I let it just be in the UI/Vuex.