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:

  1. If I store rarely updated data in the backend, I will waste bandwidth with every call to that data.
  2. 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.
  • users don't like updates. Just for the record. It's August 2021 and users are already used to updates! They are updating apps all the time on their phones. As for Electron, it's JS, could not be easier to pull updates asynchronously and do hot deploys for irrelevant things such as a list of countries. The key is making updating policies user-friendly. For example, do not force them. Don't stop the app. A simple banner informing of newer versions or asking to restart now or later is something we all already got used to.
    – Laiv
    Commented Aug 18, 2021 at 12:40

2 Answers 2


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:

  • Deploy an application update
  • Set up so the application infrequently checks the server for updates that can be downloaded without needing an application update

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

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.


On the client, store the list of countries and a version number. Then have a request to the server “give me the list of countries, but I have version X”. The request returns the last version number on the server, but only returns the country list if the caller passed a different version number than the current one. Guarantee that the server version number is never 0, so on the first call a caller just passes 0 as the version number.

So you get the optimisation except once per client if the list changes.

  • 1
    In addition to this answer. It might interest ETag
    – Laiv
    Commented Aug 18, 2021 at 8:57
  • Yes, there's a whole web server infrastructure to distribute cacheable data objects called "files", you should look into that
    – pjc50
    Commented Aug 18, 2021 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.