How to validate arguments

[eskimoblood]

We had a working solution to validate input arguments using directives and SchemaDirectiveVisitor. We imported it from apollo-server. As we try to update and apollo removes the exports from graphql-tools, I found out that also SchemaDirectiveVisitor isn't part of graphql-tools anymore but that this is the way to work with custom direct.

During my research I also found that GraphQLArgumentConfig returned by mapSchema doesn't even have a resolve function. So I wonder if there is any way to validate query arguments using directives like this:

type Person {
  id:ID!
  name: String! 
}

type Query {
    person (id: ID! @isValid): Person
}

directive @isValid on ARGUMENT_DEFINITION

[yaacovCR]

Great question!

Anything you want to do at runtime probably involves wrapping field resolvers.

what you probably want to do is something like running mapSchema once without modifying the schema, just analyzing it, ie collect field arguments that have whatever directives, and then running it again to modify your resolvers based on that analysis

[n1ru4l]

I also wanna add my opinion to this discussion. If the API consumers are programmatic clients I would consider using directives (with resolver wrapping using mapSchema) or custom scalars for doing this. However, in case a mutation is executed by a web client I would instead do the validation within the mutation resolver and based on the validation result (invalid/valid) return a Success/Failure ObjectType (e.g. via a union type) that describes the error so that information can be used to display the actual reason on the frontend in a type-safe way. Using the graphql errors array is often cumbersome, limited and not introspectable, thus not predictable.

I wrote about this here a while back: https://blog.logrocket.com/handling-graphql-errors-like-a-champ-with-unions-and-interfaces/

[yaacovCR]

Makes me rethink then as you probably want something similar for queries as mutations!

[n1ru4l]

Another interesting approach could be to not use the annotated schema for wrapping the resolvers - but for generating validation code (e.g. Yup or Joi models) with graphql-codegen, that you then can import and call individually within your resolvers 🤔

[eskimoblood]

Still the question is, do Arguments have a resolver? From reading the graphql docs it doesn't look like:

Also as this is a check against a malicious input from an attacker that could not happen from inside our clients directly, having a union including the error is not really needed here.

[n1ru4l]

Arguments and Input fields do not have resolvers. You would wrap the field resolvers that use these arguments. Creating an abstraction for validating based on directives is also in our backlog for envelop: n1ru4l/envelop#477 There the idea is to not do it as part of the resolver phase but as part of the validation phase, so an operation with invalid arguments is never executed.