graphql/envelop/plugins/use-response-cache

[giscus[bot]]

graphql/envelop/plugins/use-response-cache

GraphQL Envelop Documentation

https://the-guild.dev/graphql/envelop/plugins/use-response-cache

[martin-cycle]

Thanks so much for this, this is great work 🔥 Would be awesome to have a way to invalidate the cache all at once because if you don't setup a ttl at first, you may endup with a never invalidated cache even after adding new cache restriction in the config.

[EmrysMyrddin]

Thank you 😄
That's a good idea, can you open an issue for this ?

Waiting for an implementation, you can probably make a very simple custom cache implementation to add this feature for yourself:

import { createInMemoryCache, Cache } from '@graphql-yoga/plugin-response-cache'

export function createCache(): Cache {
  let cache  = createInMemoryCache()
  return {
    get: (...args) => cache.get(...args),
    set: (...args) => cache.set(...args),
    invalidate: (...args) => cache.invalidate(...args),
    purge: () => {
      cache = createInMemoryCache()
    },
  }
}

[martin-cycle]

-> #2131

[lagden]

The cache doesn't look at the headers.
I send x-unit: 10 on the header to get right data from unit.
So, in the next call is set x-unit: 15, but the cache returns data from x-unit: 10

[EmrysMyrddin]

Hi, you can customize the cache key generation to include additional headers:

import { useResponseCache, hashSHA256 } from '@graphql-yoga/plugin-response-cache'
useResponseCache({
	buildResponseCacheKey: (params) => hashSHA256([
		// This is the default cache key generation
	    params.documentString,
	    params.operationName ?? '',
	    jsonStableStringify(params.variableValues ?? {}),
	    params.sessionId ?? '',

		// You can add anything you want to narrow the cache key matching
		params.request.headers.get('x-unit'),
	].join('|'));
})

[lagden]

Thanks @EmrysMyrddin!

I will implement that.