Option to turn off cacheControl

[rizowski]

Problem

I was looking for a way to turn off cacheControl types from being injected into my schema. There isn't any documentation around this from what I could see. So when I dove into the code, I found the only way to turn off cacheControl is to create an executable schema instead of passing in typeDefs.

Code in question

https://github.com/apollographql/apollo-server/blob/master/packages/apollo-server-core/src/ApolloServer.ts#L150-L175

    if (schema) {
      this.schema = schema;
    } else {
      if (!typeDefs) {
        throw Error(
          'Apollo Server requires either an existing schema or typeDefs',
        );
      }


      let augmentedTypeDefs = Array.isArray(typeDefs) ? typeDefs : [typeDefs];


      // We augment the typeDefs with the @cacheControl directive and associated
      // scope enum, so makeExecutableSchema won't fail SDL validation
      augmentedTypeDefs.push(
        gql`
          enum CacheControlScope {
            PUBLIC
            PRIVATE
          }

          directive @cacheControl(
            maxAge: Int
            scope: CacheControlScope
          ) on FIELD_DEFINITION | OBJECT | INTERFACE
        `,
      );

Proposed solution

Can we get a way to turn it off much like uploads? Have a boolean option that can be set to false. I think it would be a little more clear.

Example

const server = new ApolloServer({ typeDefs, uploads: false, cacheControl: false });

Other stuff

Where can future users find this information in the docs?

[abernix]

Thanks for opening this!

It definitely seems reasonable that your schema would not need to be needlessly augmented with @cacheControl directives if cacheControl was explicitly set to false.

Though we'll have to hold off on making this change until a major version since some existing users might have used @cacheControl directives within their schema, but also (or have since) disabled cacheControl by setting it to false. While those directives wouldn't be adding as much value in a disabled state, by implementing what you're suggesting here without doing it as a noted breaking change (e.g. semver major), we'd be unable to validate against such a schema (with missing directive declarations) and operation execution would fail.

I'll tag this for Apollo Server 3!