Is it possible to expire cache?

[nahtnam]

Hello!

I'm working on a new tab page extension for chrome so my react app is opened and closed multiple times in short bursts. I am looking into storing the cache into localStorage and rehydrating it. This seems easily doable with the offline support of GraphCache. What I'm wondering is if it was possible to tell the cache for a query to expire after a few minutes. For example I don't want the user information to be fetched every time a new tab is opened but rather once every minute. Is this something doable? I can't seem to find anything in the docs but I may be looking in the wrong place

[nahtnam]

Another issue I might face is that I have an endpoint that returns a random image. So if I query randomImage ten times then the cache might hold onto 10 Image objects in the cache so it would also be nice to have them expire after a few minutes as well

[kitten]

Hiya 👋

Happy to hear you're interested in using Graphcache's offline support!
To include some context, generally our approaches are really modular, as you've noticed, so we don't include many features in each exchange past a single purpose they fulfil. For Graphcache that means that it doesn't store any time stamps or staleness data, since one of its goals is to be performing and another is to reduce memory usage. This would further be complicated by having to persist a lot of time stamps.

But we did think about this problem in particular and have an alternative solution. We have an exchange that alters when operations are refetches from the API based on an in-memory timestamp per query: https://formidable.com/open-source/urql/docs/api/request-policy-exchange/

This solves the issue elegantly while keeping the extra code and stored timestamps to a minimum. This works nicely because our "request policies" are a separate piece of logic for which the exchanges (specifically the caches) determine what to do on a match or mismatch.

It doesn't persist the timestamp though, which would be easy to add, but we chose not to since it's still a good idea to use cache-and-network when an app is reopened to update data in the background.

Another issue I might face is that I have an endpoint that returns a random image. So if I query randomImage ten times then the cache might hold onto 10 Image objects in the cache

To address this separately, this shouldn't be an issue. Graphcache garbage collects unreachable entities, so everything that's been fetched from your API but isn't referenced anymore is deleted.

[nahtnam]

Hey! Thank's for the response! I didn't see the request-policy-exchange plugin before. It looks exactly like what I need but at the same time it looks like the TTL is global. However generally the expiry time for my items are variable based on what they are. Is there a way to specify a TTL for each query? I don't see that option in the docs.

Great to hear that the cache is auto-cleared as well

[kitten]

We currently don't support query-based TTLs in there. That said, I'd say that's not really what you're looking for. I'd expect field-based TTLs at most. But then again, it's fine to refetch often via cache-and-network, as this exchange does, as it only refetches in the background, which means that the impact will be minimal on the user experience.

[nahtnam]

Hmmm, but what about things like background image. I randomly fetch one each time so it would be quite weird if an image is loaded and then a few seconds later is swapped out. Anyways, I think at that part of the code I will use the client instead of hooks so it shouldn't matter

[nahtnam]

Hmmm Ive been benchmarking both Apollo Client and URQL because when opening a new tab performance really matters and I've noticed that URQL is slower than Apollo even tho its smaller. To benchmark I:

1. Started performance profiling
2. Hard refreshed the page
3. Counted the time from load to LCP

URQL was around 300ms and Apollo was on 250ms

[kitten]

We have a lot of benchmarks and I don't want to be this "on the nose" but our normalised cache outperforms Apollo's by an order of magnitude 😅 I believe you may have only measured a single data point and included the variable server-time. JS parse times & execution time will be consistently lower. We're still working on making our tachometer benchmarks more accessible and easily usable however

[nahtnam]

Hmmm, I agree my "benchmark" is quite flawed. However there were actually no network requests made either, I just had the provider and some other hooks which were synchronous (but quite heavy). Regardless I was actually trying to test how much overhead instantiating ApolloProvider + cache is versus URQL + cache. I'll re-run the test again this time with React's profiler to see how much overhead it costs. For this app I don't really care too much about how fast or slow it is after its opened, its the initial boot that I'm trying to speed up

[frederikhors]

@nahtnam publish your code.