Validation in Input types proposal

[syrusakbary]

Validations in GraphQL-js

I would like to open a discussion around validation.

I think could be a great idea permit validation in input elements: GraphQLInputField and GraphQLArgument.
This would not involve any spec change as it relies on the implementation (as the resolve method).

Right now is possible to achieve this by using a custom GraphQLScalar per validation.
However, by doing this we have to create a new type just for validation and is not easy to compose multiple validation rules without creating a type for each composition.

Also, is possible to achieve it by add the validation logic in the resolver method, however things get trickier when we want to validate nested input data.

So, will be much simpler to have this in the implementation.

Handling errors

We could have two ways for handling validation errors:

• Not executing the query
• Executing the query excluding the fields with non-valid input, and add the validation error to the context.

Example usage

const queryType = new GraphQLObjectType({
  name: 'Query',
  fields: () => ({
    getUser: {
      type: User,
      args: {
        email: {
          description: 'The email of the user',
          validators: [email_validator],
          type: String
        }
      },
      resolve: (root, { email }) => {
        // We know we received a proper input, so this simplifies the resolver logic
        return getUserByEmail(email)
      },
    },
  })
});

Implementation

The implementation of this should be really simple, as it could be achieved by creating a new validation rule.

[helfer]

I like the idea, definitely gives the code more structure.

As for what should happen when validation fails: I strongly believe that the whole query should be rejected, because otherwise the developer has to start reasoning about all possible cases where part of the arguments get accepted, but others not. It's just much easier to deal with clear success/failure and not having to worry about the whole gray area in between.

[leebyron]

This is a good idea.

Currently you can emulate it by doing something like:

const queryType = new GraphQLObjectType({
  name: 'Query',
  fields: () => ({
    getUser: {
      type: User,
      args: {
        email: {
          description: 'The email of the user',
          type: String
        }
      },
      resolve: (root, { email }) => {
        email_validator(email);
        // We know we received a proper input, so this simplifies the resolver logic
        return getUserByEmail(email)
      },
    },
  })
});

Assuming the email_validator is a function which works like an assertion: returning void and throwing an error if invalid.

However this waits until field execution time which doesn't match @helfer's suggestion of rejecting the entire query. I agree that bad input should be considered a "developer error" and therefore block the whole query.

Validation is perhaps the right place to put this (and variable value validation, right before execution) - however we can run into the case where client tools which perform validation may falsely mark a query as valid when the server would then reject it because only the server knows about these validation rules. Maybe this is just okay? I'm not sure.

[syrusakbary]

Thanks for the reply @leebyron :)

we can run into the case where client tools which perform validation may falsely mark a query as valid when the server would then reject it because only the server knows about these validation rules.

That's completely right, but happens the same with scalar types, in which both client and server have to know what this scalar type means and how to deal with it. I think is worth to think about validation in the validate context and not in the executor.

New GraphQL type proposal: GraphQLValidationType

Maybe adding a validation type to the schema would be a good approach. So both server and client have to know how to deal with that.

schema {
  query: Query
}

validation EmailValidator

type Query {
  name: String! # String[Required] ?
  email: String[EmailValidator]
}

Perhaps GraphQLNonNull is just another kind of validation on top of a type 😉

Validation operation proposal

Another thought I had was adding a new operation type asides of query, mutation, subscription; validation. So actually clients could validate queries without actually executing them in server-side.

PS: I'm just throwing some thoughts about how we can approach this problem, with the willing of opening a discussion that could help GraphQL usage in more scenarios

[syrusakbary]

(maybe this is a conversation that could be opened in the spec repo instead of here)

[OlegIlyenko]

After looking at decorators proposal, I got a feeling that it may also this use-case as well: https://github.com/apollostack/graphql-decorators. We had a discussion about it here https://github.com/apollostack/graphql-decorators/issues/1 - with some modifications to proposal it would be possible to perform the validation before the actual execution and reject the whole query if it is invalid.

[iamchenxin]

@syrusakbary I made a solution (flow-dynamic ) for this too. dynamic check data,and also gives them a corresponding Flow Type. ex:

const resolver = (src:any) => {
  // .... doing something
  return src;
});

can be checked like this

const wrappedFn = check1(
(v) => ({
  mail:pro.isString.isEmail(v.mail) // check src.mail.
}), (v) => { // Now, the input data is validated and have a Flow type {mail:string}
  // .... doing something
});

The demonstration is here graphql-relay pr:89 (detail codes)

[syrusakbary]

@OlegIlyenko I think a better validation system is more related to the core than hacking around decorators.
@iamchenxin doing the validation in the resolving phase will not stop execution, and for validation I think is somehow essential.

A recent comment in Stackoverflow about it: http://stackoverflow.com/questions/37665539/mixing-of-schema-level-and-app-level-errors-in-graphql

Extra thoughts

Adding a new optional validate token into the language.
It could let us to do validation without any execution.

validate query MyQuery {
    # ...
}

or

validate mutation MyMutation {
    # ...
}

@leebyron ?

[iamchenxin]

@syrusakbary Error process for resolver is in execute.js#L603. Maybe it should give users more control for error behavior.(by token or by a graphql special exception name).
.or maybe give them both? in addition to token, also can assign an exception name/class which Let us to have a chance to stop current execution(pass though that exception out of graphql).
and maybe there should be some standard exception name in graphql which means STOP ,not only ignore.To stop a execution , exception is one of the standard code pattern.
maybe cause i come from other language,that makes me more like using exception to express an exception.

[OlegIlyenko]

@syrusakbary I think it depends on what shape decorators will take. I agree that that it would be great to have validators as a core concept in the library, or at least very good integrated. On the other hand all implementations already have a query validation mechanism, which is also present in the reference implementation. I think it can be beneficial to use it, but in order to do so one need a bit more information/meta-information on a field and argument level.

It's similar concept to the one I described on the decorators discussion. One nice property of this approach is that validation mechanism (as implemented in reference implementation) is able to see the whole query and all of the arguments of a field. This makes it easier to implement validation rules that validate several interdependent arguments at once (like, for instance, password and passwordConfirmation).

[jedwards1211]

@OlegIlyenko yes, being able to compare arguments during validation is very important -- but such a thing could also be achieved by simply having a validate function called with all the same arguments as the resolve function before the query is executed.

[jedwards1211]

One of the cases where client/server differences could arise (concerning context-free syntax validation) would be if old clients are connecting to a server with an updated schema. So I think an app must be structured so that the server can send back errors that the client will handle just the same as if they had occured in client-side validation.

[xpepermint]

Ow yeah... built-in validations - GraphQL would become a perfect tool! We need this... :). I've been using custom scalars for months but I found it not appropriate. Also most of my projects were using forms (form validation) and I needed to send user-friendly validation errors to a user (to a form; a custom validation error code would be enough here).

I think that user-friendly validation errors are important. What I use now in my GraphQL projects is similar to Konstantin Tarkus's proposal - smart.

mutation {
  createUser() { // returns UserMutationType
    data: {name} // null if invalid
    errors: {message, code} // validation errors
  }
}

To make my resolvers small I wrote a helper package which handles validation and error handling in a way I need (e.g. MongoDB E11000 error can also be treated as validation error thus I can respond with already taken validation error message instead of the unreadable MongoError warning). Here is how my resolvers currently look like using Approved.js:

import {user} from '../approvals/users';

export async function createUser(root, args, ctx) {
  let data, errors = null;
  try {
    await user.validate(data, ctx);
    let res = await ctx.mongo.collection('users').insert(data);
    data = res.ops[0];
  } catch(err) {
    errors = await user.handle(err, ctx);
    if (!errors) throw err;
  }
  return {data, errors};
}

Having this kind of functionality as part of GraphQL would be just amazing!