make cache work as expected

[kkuepper]

when navigating from the homescreen to somewhere else (e.g. a playlist) and then going back, I expect the homescreen to be cached and visible instantly.
Instead it needs to wait for the response from the server.
(Note: the response from the server is currently too slow and will be improved as well)

[sifferhans]

We could try to use the getCachedData option in useAsyncData composables.
https://nuxt.com/docs/api/composables/use-async-data#params

[SimonSimCity]

Ok, so tell me please, what is expected?

Currently our API implementation works with promises. A promise returns once. When implementing caching on this implementation, we'll have to choose whether to deliver an maybe outdated result (the cached one) or let the user wait a little longer; we cannot "deliver once (the cached response, or just the servers response if there's nothing cached) and maybe twice (in case we have a cached value and the server has an updated response)".

Continuing this way, we'll have to choose if and when we will send a request to the server despite having a cached value. Let's make it easy and say that we want to agree on one TTL for cached values, not a different one per URI. Another question here would be if the user can force-reload the content, and how.

Another approach would be to follow what Angular has been doing, to use pipelines (like RxJS), which can return multiple times. It uses this to both return the cached value immediately but also to send a request to the server. The only question remaining is then: How do we want to notify the user if the cached content he is already presented with, is outdated? Some apps show a notification, others just replace the content, which might be perceived as being unstable, if the user doesn't expect the content to change without his interaction (like in a collaborative environment).

Just this... we could show a notification somewhere generally if a response is outdated and the server has a newer response, but to me it's questionable whether we want that.

Just this: The question of how it should be for the user should guide the technical decision of how to realize this, not vv. We can always start small and grow, but we shouldn't start crippled, because we don't want to invest some time to outline where we want to be.

[kkuepper]

I think for now, I wouldn't cache anything. Most people use it on their PC with good internet connections. Therefore our efforts are better spent in other areas.

[SimonSimCity]

One of the reasons we've had caching in mind was the idea of allowing people from places with low bandwidth (e.g. Africa) to have a good experience when using the website/desktop app. We will have to see what other solutions they propose (e.g. Setting up an nginx-caching on a raspberry pi). Some of the solutions do not require us to prepare anything special, so I agree with having this ticket being on hold until this is talked about, after which we will reevaluate the priority.