makeExecutableSchema should permit directives

[voodooattack]

Since the schema language now allows directives, makeExecutableSchema should pass on the directives argument to the GraphQLSchema constructor.

type GraphQLSchemaConfig = {
  query: GraphQLObjectType;
  mutation?: ?GraphQLObjectType;
  subscription?: ?GraphQLObjectType;
  types?: ?Array<GraphQLNamedType>;
  directives?: ?Array<GraphQLDirective>;
};

[helfer]

@voodooattack indeed, can you make a PR please? 🙂

[voodooattack]

@helfer I was thinking maybe something like an attachDirectivesToSchema function?

The problem I see is that there are two ways to use directives, the first is before the schema is constructed (AST manipulation using directives like decorators, something like this: https://gist.github.com/voodooattack/e12f1e451f9b82bc20cec1a49e44e23a), and the second is to interpret client requests (in which case, the directives would act on the schema and modify the resolvers).

How do you suggest we go about this?

[stubailo]

What would the new directives even do? Would they be passed into the resolvers somehow?

[voodooattack]

@stubailo Here's a use case https://github.com/lirown/graphql-custom-directives

[stubailo]

Wow, I did not know that was a thing you could do! I think adding a new option to makeExecutableSchema would be the way to go. Under the hood perhaps it could be implemented via an attachDirectivesToSchema function.

Please send a PR!

[voodooattack]

@helfer @stubailo Here's another example that generates a full database backend from schema language definitions with directives. https://gist.github.com/voodooattack/ce5f0afb5515ab5a153e535ac20698da

PS: I'd send a PR, but I'm not entirely clear on the big picture yet. What should the API look like?

[helfer]

@voodooattack the best way to start in my opinion would be to write a design doc similar to the ones we have in apollo client. The design doc should explain what feature you're adding, how it works, why it's useful and provide a few examples for how to use it. That way we can provide feedback on the idea before too much code is written.

[helfer]

@voodooattack are you still interested in this? I think the API could simply be to add an additional argument for directives to the makeExecutableSchema function and pass that through to graphql-js.

[DxCx]

this can be a great feature! 👍

[helfer]

Closing this for lack of activity. If you're still interested, please send us a PR @voodooattack ! 🙂

[timbrandin]

Hey people, I have successfully implemented attachDirectivesToSchema locally, I'm not sure where in this code it fits, but this is how it looks.

// directives.js

import { chainResolvers } from 'graphql-tools';

export default {
  translate: (value) => {
    // Translate field value.
    return value;
  },
};

// Helper to attach directives to the schema.
export function attachDirectivesToSchema(info, directives) {
  function attachSelectionSetDirectives({ selections }, parentType) {
    return selections.forEach((selection) => {
      const key = selection.name.value;
      const typeDef = parentType._fields[key]; // eslint-disable-line
      if (typeDef) {
        const fieldNodeType = typeDef.type.ofType || typeDef.type;
        const directiveResolvers = selection.directives.map((directive) => {
          const name = directive.name.value;
          const params = directive.arguments.reduce((acc, arg) => ({
            ...acc,
            [arg.name.value]: arg.value.value,
          }), {});
          if (directives[name]) {
            return (obj, args, ...rest) => directives[name](obj, { ...args, ...params }, ...rest);
          }
          return null;
        }).filter(x => !!x);
        // Keep track of the original resolver.
        if (!typeDef.original) {
          typeDef.original = [typeDef.resolve];
        }
        // Chain the resolvers for the directives.
        if (directiveResolvers.length > 0) {
          typeDef.resolve = chainResolvers([
            ...typeDef.original,
            ...directiveResolvers,
          ]);
        } else if (typeDef.original) {
          typeDef.resolve = typeDef.original[0];
        }
        // Recurse down the selectionSet.
        if (selection.selectionSet) {
          attachSelectionSetDirectives(selection.selectionSet, fieldNodeType);
        }
      }
    }, {});
  }

  return attachSelectionSetDirectives({ selections: info.fieldNodes }, info.parentType);
}

// schema.js

import directives, { attachDirectivesToSchema } from './directives';

const resolvers = {
  Query: {},
};

const typeDefs = `
  type Query {
    field: String
  }

  schema {
     query Query
  }

  directives @translate on FIELD
`

const schema = makeExecutableSchema({
  typeDefs,
  resolvers: {
    ...resolvers,
    __schema: (obj, args, context, info) => {
      attachDirectives(info, directives);
      return obj;
    },
  },
});

My first idea was to chain in a directive resolvers on every field in the build step and look at the info for any directives at the current level and determine if it should run, but I quickly realised that this method would run way to much. So my second attempt is this where I jointly go through the query and corresponding type, and if found any directives at each level I chain them in after the original resolver has executed. One drawback is that the schema is mutable so one have to remove any leftover directives on fields that had them before, and also make sure they don't start stacking up more and more that will be executed.

But anyhow, this way it's easy to add directives to the schema.

I hope it helps someone!

Cheers,
// T

[helfer]

Hey @timbrandin! That looks interesting. Do the directives get attached on every request? If so, is that necessary, or could they be applied to the resolvers at the time when the schema is built?

[timbrandin]

They do get attached on every request. My initial idea was as you mention to attach a filter to every field which would determine which and if a directive should be executed. But I came to the conclusion that having a filter on the request walk through the query and attach would be less resource demanding than a filter that ran for every field on every request, but of course I haven't done the math for this so I could be wrong.