graphql - GraphQL 中的输入类型有何意义？

Question

您能否解释一下为什么如果突变的输入参数是对象，那么它应该是输入类型？我认为简单得多，只需重用 type 而不提供 id。

例如:

type Sample {
  id: String
  name: String
}

input SampleInput {
  name: String
}

type RootMutation {
  addSample(sample: Sample): Sample  # <-- instead of it should be
  addSample(sample: SampleInput): Sample
}

对于小对象来说还可以，但是当架构中有大量具有 10 多个属性的对象时，这将成为一种负担。

Answer 1

来自规范:

The GraphQL Object type (ObjectTypeDefinition)... is inappropriate for re‐use [as an input], because Object types can contain fields that define arguments or contain references to interfaces and unions, neither of which is appropriate for use as an input argument. For this reason, input objects have a separate type in the system.

这是“官方原因”，但是有几个实际原因导致您不能使用对象类型作为输入对象类型或使用对象类型作为输入对象类型:

功能

对象类型和输入对象类型都具有字段，但是这些字段具有不同的属性，反射(reflect)架构如何使用这些类型。您的模式可能会为对象类型的字段定义参数和某种解析器函数，但这些属性在输入上下文中没有意义(即您无法解析输入对象的字段 -它已经有一个明确的值)。同样，只能为输入对象类型字段提供默认值，而不能为对象类型字段提供默认值。

换句话说，这可能看起来像是重复:

type Student {
  name: String
  grade: Grade
}

input StudentInput {
  name: String
  grade: Grade
}

但是添加特定于对象类型或输入对象类型的功能可以清楚地表明它们的行为不同:

type Student {
  name(preferred: Boolean): String
  grade: Grade
}

input StudentInput {
  name: String
  grade: Grade = F
}

类型系统限制

GraphQL 中的类型分为输出类型和输入类型。

输出类型是可以作为 GraphQL 服务生成的响应的一部分返回的类型。输入类型是字段或指令参数的有效输入的类型。

这两组之间存在重叠(即标量、枚举、列表和非空值)。但是，诸如联合和接口(interface)之类的抽象类型在输入上下文中没有意义，并且不能用作输入。将对象类型和输入对象类型分开可以确保在需要输入类型的地方永远不会使用抽象类型。

架构设计

当在架构中表示实体时，某些实体可能确实会在各自的输入和输出类型之间“共享字段”:

type Student {
  firstName: String
  lastName: String
  grade: Grade
}

input StudentInput {
  firstName: String
  lastName: String
  grade: Grade
}

但是，对象类型可以(并且实际上经常这样做)对非常复杂的数据结构进行建模:

type Student {
  fullName: String!
  classes: [Class!]!
  address: Address!
  emergencyContact: Contact
  # etc
}

虽然这些结构可能转换为适当的输入(我们创建一个学生，因此我们还传入一个代表他们地址的对象)，但通常它们不会 - 即，也许我们需要指定学生的类 ID 和节 ID，而不是对象。同样，我们可能有一些想要返回但不想改变的字段，反之亦然(例如 password 字段)。

此外，即使对于相对简单的实体，我们也经常对对象类型及其“对应”输入对象之间的可空性有不同的要求。通常我们希望保证响应中也会返回某个字段，但我们不想在输入中设置相同的字段。例如，

type Student {
  firstName: String!
  lastName: String!
}

input StudentInput {
  firstName: String
  lastName: String
}

最后，在许多模式中，给定实体的对象类型和输入对象类型之间通常不存在一对一的映射。一种常见的模式是针对不同的操作使用单独的输入对象类型来进一步微调架构级输入验证:

input CreateUserInput {
  firstName: String!
  lastName: String!
  email: String!
  password: String!
}

input UpdateUserInput {
  email: String
  password: String
}

所有这些示例都说明了一个重要点 - 虽然输入对象类型有时可能会镜像对象类型，但由于业务需求，您在生产模式中看到这种情况的可能性要小得多。