@treorisoft/graphql-validator-directive

Allows creating custom constraint directives to validate queries and inputs. Inspired by graphql-constraint-directive.

This is useful for output types as well - since this consolidates directives rather than relying on individual field resolvers which might have the directive run the same validation check multiple times.

Setup

There are multiple parts to setup and use this.

Create Directives

First create the custom directives and ensure they are part of your schema.

Currently the only supported directive locations: FIELD_DEFINITION | INPUT_FIELD_DEFINITION | ARGUMENT_DEFINITION

1directive @isAuthenticated(message: String) on FIELD | FIELD_DEFINITION | INPUT_FIELD_DEFINITION

Create Rule

Next create the rule that will handle the directive. See the Usage section for further details.

1import { ValidationDirectiveRule } from "@treorisoft/graphql-validator-directive";
2
3export default class IsAuthenticatedDirectiveRule extends ValidationDirectiveRule<Record<string, any>, any, unknown> {
4  async execute(context: unknown): Promise<void> {
5    if (!context.auth) {
6      throw new Error('Not authorized: ' + this.args.message);
7    }
8  }  
9}

Register Rule/Transform Schema

Now we need to register the rule with the directive and transform the schema to initialize them.

1import { schemaTransformer, registerRules } from '@treorisoft/graphql-validator-directive';
2import IsAuthenticatedDirectiveRule from './directives/isAuthenticatedRule';
3
4registerRules({
5  isAuthenticated: IsAuthenticatedDirectiveRule,
6});
7
8export function mergeDirectives(schema: GraphQLSchema): GraphQLSchema {
9  return schemaTransformer(schema);
10}

Setup the plugin

1import { createApolloValidationPlugin } from '@treorisoft/graphql-validator-directive';
2
3const server = new ApolloServer<ResolverContext>({
4  schema,
5  plugins: [
6    createApolloValidationPlugin(),
7  ]
8});

Usage

execute is a required abstract method that performs the validation for the given field and receives the same context that would be passed to any field resolver.

There are 3 ways to signal an failure.

Return a boolean false, return a string with the error message or simply throw an error.

Depending on just what kind of validation is taking place the effect of the failure will be different.

• Input validation, or top-level query/mutation fields will cause an error to be thrown.
• Type field validation:
  • If your rule throws, it will be thrown before anything is run
  • If you return a failure (false or string), your field will be removed from the selection set and pretend that it wasn't even requested.

Development

Development of this package is done via a larger monorepo where this is a git submodule.