Assume we are building a Progressive Web App(as everyone does these days) that communicates with the server through a rest API. Now I need to show a list of world countries to the user to choose from.
I have a table with valid world countries in the backend that I use to validate requests, but the problem is, it seems a waste of bandwidth to fetch a list of say 240 countries from the backend every time the user is interacting with the country picker. Of course this would be necessary if data changed frequently, but countries in the world don't change that often. Storing the list as a JSON in the frontend too has its own problem, what should I do if the list changes? Push an update to all clients? (considering the app may be turned into a REAL app with electron or Cordova and users don't like updates)
Now world countries are just an example and the cost of the request to the server can be much higher, for example, if I want to draw growth charts for a child I need 1MB of reference data and getting all that from the server every time is not ideal.
To summarize:
- If I store rarely updated data in the backend, I will waste bandwidth with every call to that data.
- If I store rarely updated data in the frontend(Client), I will have to push an update if the data ever changes and users will hate it.
Best Answer
The decision between offline/online storage is a balance between volatility (data change rate) and efficiency (bandwidth/performance from network call).
As you're dealing with low volatility, there's little issue with storing these details offline. This mean that when the data does change, you either:
1MB isn't excessive, but be aware that there is a reasonable size limit on how much data you store on the user's device; unless it is contextually obvious to the user that your application is a bulky one.