为什么 GraphQL 变量突变语法如此冗余？

Question

GraphQL 查询/突变非常简洁：它们只需要它们实际需要的东西，没有别的。或者至少是基本的。

但是，如果您将变量与其中任何一个一起使用，那么您的语法不可避免地会出现冗余：

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

注意$episode: Episode 和episode: $episode。问题是每个 GraphQL 突变都需要相同的冗余：如果您使用变量，则每个参数都必须定义两次（如果您正在进行 programmatic 查询，那么您无疑是在使用变量）。

我的问题是，为什么？让每个使用 GraphQL 的人都不得不重复他们的论点似乎没有必要。

为什么不直接写语法：

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

或者如果你真的需要允许不同的变量名，允许一个可选的第三部分：

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

需要明确的是，我知道使用变量的查询与非变量的查询不同，但我要问的是，为什么要为那些迫使每个人重复自己的查询选择一种语法？

看起来如此......不干燥！我肯定错过了为什么这种重复是必要的一个重要原因？

Answer 1

为什么我必须在 JavaScript 函数中列出我的参数？功能不明显吗

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

接受两个参数，一个名为firstname 一个名为lastname?好吧，我认为在这里很容易看穿，但是在更复杂的情况下，它并不那么明显。现在上面的例子看起来很奇怪，但是在一些函数式编程语言中，(_ + 2) 和 _.concat(_) 这样的表达式是有效的函数表达式。你可以创建一些非常讨厌的代码（看着你，点免费的 Haskell）。但是很多语言似乎认为明确声明一段代码的输入是个好主意。

回到 GraphQL：让我们看看变量的一些更复杂的用法，因为变量实际上是一个完整的变量实现。您可以使用它们做更多事情，然后将它们应用于参数：

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

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

所以变量可以在很多地方使用，也可以多次使用。 GraphQL 查询很少会变得非常大。这适用于您提出的第二种语法吗？是的，但我认为可读性会受到影响。 DRY 并不是要减少您必须输入的字符数量，而是要减少错误。但是，经常对事物进行明确也可以减少错误（例如，如今很多类型系统都在明确输入参数及其类型）。

所以我想这只是 GraphQL 的开发人员做出的一个交易决定，他们选择了显式版本。不要忘记背景：GraphQL 是在 Facebook 上创建的，Facebook 是世界上最大的网络应用程序之一。

由于显式的好处并不明显，这里编辑列出了一些：

• 该声明允许开发人员快速了解查询中的所有变量及其对应类型。
• GraphQL 开发人员工具不必从架构中推断出变量的类型，而只需查找输入类型即可。
• 错误消息变得更容易理解，假设参数showAll 不采用布尔值而是整数。通过声明，我们可以说mismatching types for variable $long. $long is Boolean but expected Int。如果没有声明，我们将不得不说$long is sometimes used as Boolean, sometimes as Int。如果我们将其用作三种不同的类型会怎样？
• 只能通过 GraphQL 静态代码分析来检测中断查询：再次假设我们将 showAll 的类型更改为 Int。在这种情况下，查询可能会被检测为错误，而如果没有显式类型声明，查询可能会在运行时中断。