[response-cache] - Mark fields as cacheable via directive

[klausXR]

I would like to add a custom directive, like @Cacheable that is added to graphql type definitions.

When a query comes, after it is parsed, I would like to verify that the types queried by the client are all marked as cacheable ( cache opt-in ), if so, the cache should be enabled, else - disabled.

How should I implement such feature with the response-cache package?

[n1ru4l]

You can use an AST visitor for building the configuration (https://graphql.org/graphql-js/language/#visit).

Pseudo Code:

import { visit} from "graphql"
function buildResponseTTLCacheConfig(schemaAST) {
  const config = {
    ttlPerSchemaCoordinate: {}
  }
  visit(schemaAST, {
    Directive(node) {
       // check if directive is Cacheable and whether it is applied on a field...
       ttl[ttlPerSchemaCoordinate][name] = ???
    }
  })
  return ttl
}

useResponseCache({
  ...buildResponseTTLCacheConfig(schemaAST),
})

[n1ru4l]

Any reasons why you would calculate this information again and again as the operations are incoming instead of once when the server is starting?

the useResponseCache is using that extracted information internally when it is resolving the fields, see https://github.com/dotansimha/envelop/blob/main/packages/plugins/response-cache/src/plugin.ts

[klausXR]

Because a specific type may make the entire query uncacheable if statically analyzed, however, if the client didn't query that type, it should be cacheable.

This repetitive work also occurred to me and it doesn't seem to be an issue for my application, at least at the moment, so I may actually skip it, but is there a mechanism to add it back on if it ends up being necessary?

Because I'm on the verge of implementing it manually vs adding envelop for that plugin at the moment ( though I like it very much and will likely use other plugins soon ).

As an example, you might have a product, which has reviews that are uncacheable, but its images and price are cacheable. If a client only asked for images, price and title, the query should be cached.

Edit: I think I understand what you are saying. If I declare it initially on bootup, the plugin will read the values at runtime and determine whether or not it should cache the query? So, if I set the TTL to 0 on a type and at runtime its resolver executes, it should make the query uncacheable?

[n1ru4l]

I think I understand what you are saying. If I declare it initially on bootup, the plugin will read the values at runtime and determine whether or not it should cache the query? So, if I set the TTL to 0 on a type and at runtime its resolver executes, it should make the query uncacheable?

Yes, that is true!

[klausXR]

Okay, last question. When a query is coming, how does the plugin determine whether or not it should check the cache, when it hasn't executed any resolvers yet? Does it blindly hit the cache and continue if nothing was in it?

[n1ru4l]

Yes the cache key is built and looked up, afterwards, if there is no hit the execution continues as usual, otherwise the value from the cache is served.

See https://github.com/dotansimha/envelop/blob/aee3c21998a60b1ad2e5400f6632ea0cdd213352/packages/plugins/response-cache/src/plugin.ts#L256