Cache invalidation

[anders-kiaer]

We want to cache data in the user's browser for calculations where the raw/underlying data will not change. A long cache time where data does not change could be important when we open up for all assets, in order to reduce load on backend.

Currently the main ingredient in the "cache key" is case + iteration/ensemble.

After discussions with Sumo + fmu-dataio it might take a long time (if ever) before we get some concept of "immutable" ensemble, since one important use case is to not disrupt the way the /scratch disk is used today.

Thinking loud: In the ensemble selection dialog box, we fetch high-level ensemble metadata. If we there also fetch time of last data uploaded to a given ensemble (and periodically refetch this ensemble metadata, e.g. every 10 minutes), and append this as a query parameter to our own API GET endpoints, we could potentially use that as a way to get the browser to invalidate cache when appropriate (i.e. when we see new data has been uploaded). One potentially aesthetic downside would be that it is a query parameter which is not actually used in our own backend (it is only used to get the browser to invalidate a response cache, i.e. consider it as a completely new request).

[rubenthoms]

A common approach is to use a ServiceWorkers with the Workbox library from Chrome, in particular the workbox-broadcast-update (https://developer.chrome.com/docs/workbox/modules/workbox-broadcast-update). However, we need to tighten the updates from the ServiceWorker to our requests, which is a little challenge in itself. I.e. we need a global manager that listens to messages from the ServiceWorker and that has access to our queryClient from TanstackQuery. We then need to map the responses from the ServiceWorker to the query keys and invalidate and refetch the respective queries. We also need to make sure that all fetching functions are subscribed to changes to the query cache ( useQuery and useQueryAtom should be subscribed by default afaik). The challenging part is the mapping as TanstackQuery is not related to HTTP and only uses arbitrary keys. However, we could have a uniform approach to creating the keys (which is already covered in @api/@tanstack/react-query.gen.ts).