Why is GraphQL Variable Mutation Syntax So Redundant?

user_5921 0
Viewed 227

GraphQL queries/mutations are super clean: they only require what they actually require, nothing else. Or at least the basic ones are.

But if you use variables with either one, then your syntax inevitably has redundancy in it:

query HeroNameAndFriends($episode: Episode) {
  hero(episode: $episode) {
    name
    friends {
      name
    }
  }
}

Note the $episode: Episode and episode: $episode. The thing is EVERY GraphQL mutation requires this same redundancy: if you use variables, every argument has to be defined twice (and if you're making programmatic queries, you undoubtedly are using variables).

My question is, why? It seems so unnecessary to make everyone who uses GraphQL have to repeat their arguments a second time.

Why not just make the syntax:

query HeroNameAndFriends() {
  hero($episode: Episode) {
    name
    friends {
      name
    }
  }
}

or if your really need to allow for differing variable names, allow an optional third part:

query HeroNameAndFriends() {
  hero(episode: Episode : $episode) {
    name
    friends {
      name
    }
  }
}

To be clear, I understand that variable-using queries are different from non-variable ones, but what I'm asking about is, why pick a syntax for those queries that forces everyone to repeat themselves?

It just seems so ... not DRY! Surely I'm missing an important reason why this repetition is necessary?

graphql
1 Answers

Why do I have to list my arguments in a JavaScript function? Isn't it obvious that the function

const getFullName = () => firstname + ' ' + lastname;

takes two arguments, one named firstname one named lastname? Well I think here it is easy to see through but there are a more complicated cases in which it is not quite so obvious. Now the example above seems weird but there are some functional programming languages where expressions like (_ + 2) and _.concat(_) are valid function expressions. And you can create some pretty obnoxious code (looking at you, point free Haskell). But a lot of languages seem to think that declaring the input of a piece of code explicitly is a good idea.

Back to GraphQL: Let's look at some more complicated uses of variables because variables are really a full variable implementation. You can do more with them then just applying them to an argument:

query NestedInput($name: String) {
  user(where: { name: { contains: $name } }) { ... }
}

query WithDirective($long: Boolean) {
  users {
    name
    bio @include(if: $long)
    friends(showAll: $long) {
      name
    }
  }
}

So variables can be used in a lot of places and also be used multiple times. And not seldomly GraphQL queries become really large. Would this work with the second syntax that you have proposed? Yes, but I think the readability would suffer. DRY is not about reducing the amount of characters you have to type but about reducing errors. But often being explicit about things can also reduce errors (e.g. a lot of type systems these days are about being explicit about input parameters and their types).

So i guess it was simply a trade of decision that was made by the developers of GraphQL and they chose the explicit version. Don't forget the context: GraphQL was created at Facebook, one of the biggest web apps in the world.

Since the benefits of the explicitness are not obvious here is an edit that lists a few:

  • The declaration allows a developer to quickly understand all variables and their corresponding types in a query.
  • GraphQL developer tooling does not have to expensively infer the type of the variables from the schema and instead can simply lookup the input type.
  • Error messages get easier to understand, imagine the argument showAll does not take booleans but ints. With the declaration we can say mismatching types for variable $long. $long is Boolean but expected Int. If it is not declared we would have to say $long is sometimes used as Boolean, sometimes as Int. What if we use it as three different types?
  • Breaking queries could be detected by GraphQL only static code analysis: Again imagine we change the type of showAll to Int. In this case the query can be detected as wrong, while without the explicit type declaration the query might instead break at runtime.
user_38491670
Related