Infer arguments and their types

[mjomble]

It seems to me like there is needless repetition in queries like this:

query RollDice($dice: Int!, $sides: Int) {
  rollDice(numDice: $dice, numSides: $sides)
}

whereas using the schema, the same information could be derived from something like this:

query RollDice {
  rollDice(numDice: $dice, numSides: $sides)
}

If I leave any arguments undeclared, GraphQL tells me which ones I need to declare.
If I declare them with types that don't match the schema, GraphQL tells me what the types should be.

So basically, when writing queries like these, GraphQL is asking the user for information it already knows and punishes them (with errors) if they get any of it wrong.

Is there a good reason why it works this way instead of inferring the arguments and/or their types automatically?

[rmosolgo]

Personally, I like the clarity of the variable names, types and defaults at the top of the operation. As a reader, I can quickly see whether the variables I'm sending to the server match the ones required by the operation.

[mjomble]

I thought of this, but wouldn't you then also want to replace queries like this:

{
  hero {
    name
    friends {
      name
    }
  }
}

with something like this:

{
  hero: Character {
    name: String
    friends: [Character] {
      name: String
    }
  }
}

so you would quickly see if the types coming in from the server match the ones you use in client side code?

Seems to me like this kind of explicit type annotations should be optional, not required.

[calebmer]

The point of the type annotations is to help client tooling. Clients may easily see which variables an operation requires and enforce those variables. It also allows for a user to define default values and enforce non-nullability even when a variable is going to a non-null field. For example:

query ($nonNullArgument: String!, $defaultValueArgument: Int = 42) {
  field(
    nullableArgument: $nonNullArgument
    defaultValueArgument: $defaultValueArgument
  )
}

A type error may also be easily caught by the GraphQL server if we are trying to pass say a String into an Int. Otherwise, GraphQL would implicitly cast the String into an Int.

Also, in a world where fragments have variable definitions, these benefits may further be seen.

I like the explicit nature of the variable definitions, but if this is something you don’t like then there is nothing stopping you from writing your own GraphQL validation rules in your server implementation of choice 😊

[mjomble]

True, but it still seems inconsistent to me:

• When receiving data from the server, no type annotations are needed or even allowed, everything is inferred based on the schema.
• When sending data to the server, all types must be explicitly annotated and nothing is inferred.

Wouldn't it also help client tooling if queries that receive data were fully annotated?
And wouldn't it make sense to make these annotations optional for scenarios where client tooling is not used?

[calebmer]

The difference here is input vs. output. It makes sense to annotate input so that the server knows exactly what the client is trying to do. Output, on the other hand, is completely defined by the server and consistent across requests.

[stubailo]

I think these should be optional - they are useful to do validation or code generation, but when you're using GraphQL with a dynamically typed language where nothing is actually going to validate those arguments for you, it seems unnecessary to require these annotations.

Also, if you have tooling like Flow or TypeScript, couldn't that infer the variable types from the field arguments?

[dylanahsmith]

This issue seems like a duplicate of #251

[mjomble]

Indeed. I will close this one and follow the other one. Thanks!