InMemoryCache is not respecting the Cache-Control header

[mathix420]

Intended outcome:

I use apollo-client via @nuxtjs/apollo which is using vue-apollo which is using apollo-client.
I am using InMemoryCache to cache my queries in frontend.
On server I use the @cacheControl directive to control the cache TTL.
So I am assuming that apollo-client coupled with InMemoryCache should take care of the Cache-Control header and invalidate cached queries once the max-age has expired.

Actual outcome:

If I retry a simple query returning this header cache-control: max-age=100, public 100 seconds after the first one the cache is used, which is not intended.

How to reproduce the issue:
--

Versions

System:
  OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
Binaries:
  Node: 12.14.1 - /usr/local/bin/node
  Yarn: 1.22.10 - ~/peach_frontend/node_modules/.bin/yarn
  npm: 7.5.3 - /usr/local/bin/npm
Browsers:
  Chrome: 88.0.4324.150
  Firefox: 85.0
npmPackages:
  apollo-cache-inmemory: 1.6.6 => 1.6.6
  apollo-client: ^2.6.10 => 2.6.10
  apollo-fetch: 0.7.0 => 0.7.0
  apollo-link-error: 1.1.13 => 1.1.13
  apollo-link-http: 1.5.17 => 1.5.17

[benjamn]

@mathix420 For most issues folks are facing with Apollo Client 2, our general advice is to try updating to AC3. In this case, I have to admit updating to AC3 won't help, because Apollo Client (still) doesn't have any logic to handle cache-control HTTP headers. Someone could potentially implement an ApolloLink that handles the client side of apollo-cache-control, but I haven't seen any existing links like that. I do agree this would be useful functionality, and integrating it into ApolloClient and InMemoryCache would have some benefits that would be hard to provide with a link implementation.

If you update to AC3, https://github.com/NerdWalletOSS/apollo-invalidation-policies might give you some of the functionality you're looking for, though that won't be as automatic as what you described (which would be better, I agree).

[benjamn]

@danReynolds It seems like you've started to think about TTL with apollo-invalidation-policies. Curious if you have any intuition about how feasible it would be to derive invalidation policies automatically from HTTP headers?

[danReynolds]

@danReynolds It seems like you've started to think about TTL with apollo-invalidation-policies. Curious if you have any intuition about how feasible it would be to derive invalidation policies automatically from HTTP headers?

I'd have to dig into whether those headers are exposed in the cache APIs I'm using, if they are then I could see it being do-able although the way the current TTLs are set up by being specified on types I'd have to think about reconciling those two. Certainly something we can spike.

[Bhoomikapanwar]

Any update on this front? Does Apollo has any plans to get this in sometime soon? Or is there some suggested solution for now that can enable utilisation of cache-control headers for client's cache? Wondering how we handle possible conflicts between default & http caching then.

@danReynolds Also, Could you make the above workaround work?