Support for cache-control headers in full response cache as an option

[joao-dias-tma]

We have migrated from Apollo Server 3 and the response cache plugin there is cache-control headers which we use to store responses in Cloudflare workers as a proxy, so it bypasses our origin entirely.

However, GraphQL Yoga uses ETag which isn't that friendly with our caching proxy, and we are wondering if another alternative plugin was considered that uses cache-control headers instead. I've tried to search here and Google around but it doesn't look like anyone did such plugin.

[ardatan]

I don't think it is possible and accurate.
https://the-guild.dev/graphql/hive/docs/gateway/other-features/performance/response-caching#overall-comparison
We have this kind of comparison that shows why we use ETag instead of Cache-Control header. TTL-based invalidation prevents us to have an invalidation via mutations.

[joao-dias-tma]

We understand the limitation with invalidation and it's something we are happy to compromise on. Our use case is to avoid ETag requests (or any requests at all) if the response is still valid in our proxy CDN or in customer browser.

[ardatan]

It doesn't look accurate to return Cache-Control header with the calculated TTL as an option. Not sure if it is a good idea to have this kind of "broken" option in our plugin.
@EmrysMyrddin What do you think?

[joao-dias-tma]

I mean, it's fine if you don't want to provide Cache-Control header support out of the box, but right now there doesn't seem to be an easy way to hook into the existing response cache plugin in both GraphQL Yoga or Envelop to add the header manually via a hook or a plugin because the finalTtl doesn't seem to be exposed in any hook unless I'm missing something

[ardatan]

Actually it is exposed with onTtl
https://github.com/graphql-hive/envelop/blob/main/packages/plugins/response-cache/src/plugin.ts#L152

[joao-dias-tma]

I saw that but it doesn't allow to update the result. Are you suggesting that we save the TTL value there in a map and then fetch it later?

[ardatan]

Yes

const ttlByRequest = new WeakMap<Request, number>();
// In the response cache parameters
useResponseCache({
   // other options...
   onTtl({ ttl, context }) {
       if (ttl != null && ttl > 0) {
         ttlByRequest.set(context.request, ttl);
      }
   }
})
// Then in another plugin
{
    onResponse({ request, response }) {
       const ttl = ttlByRequest.get(request);
       if (ttl != null) {
          response.headers.set('my-header', ttl.toString());
       }
   }   
}

[joao-dias-tma]

Alright, yeah, thanks.

It would still be nice to have this support as an option out of the box, perhaps as another plugin or in addition to the existing one with some option. That would help other users migrating from Apollo Server with similar requirements. You can keep this open if you choose to do so, feel free to close otherwise.

[ardatan]

Like I said earlier, I am not sure if I am fan of supporting a broken behavior. I'll keep this open so we can discuss here with others.
cc @enisdenjo @EmrysMyrddin

[joao-dias-tma]

For future reference in case anyone needs something similar, I made this simple plugin for our own use:

import { useResponseCache, UseResponseCacheParameter } from '@graphql-yoga/plugin-response-cache';
import { Plugin, YogaInitialContext } from 'graphql-yoga';

export const cacheControlResponseCachePlugin = <TContext = YogaInitialContext>(
  options: UseResponseCacheParameter<TContext>,
): Plugin => {
  const ttlByRequest = new WeakMap<Request, number>();

  return {
    onPluginInit: ({ addPlugin }) => {
      addPlugin(
        useResponseCache<TContext>({
          ...options,
          onTtl: ({ context, ttl }) => {
            if (ttl) {
              ttlByRequest.set((context as YogaInitialContext).request, ttl);
            }
            return ttl;
          },
        }),
      );
    },
    onResponse({ request, response }) {
      const ttl = ttlByRequest.get(request);
      if (ttl) {
        response.headers.set('Cache-Control', `public, max-age=${ttl}`);
      }

      response.headers.delete('ETag');
      response.headers.delete('Last-Modified');
    },
  };
};

[EmrysMyrddin]

Personally, I don't mind that much sticking with E-Tag only.

Invalidation via mutation is also arguably a bit "broken", since you have to carefully request the updated data, otherwise you can miss some updated entities. And this invalidation via mutation have a cost, it doesn't come for free.

So I can totally imagine use cases where it doesn't matter to have a 30s old representation of the data, but where you need to massively reduce your load.

Cache is always a balance between performance and accuracy. The sweet spot depends on end user requirements, so I'm not sure we should force a "silver-bullet" solution.

@enisdenjo What is your opinion ?