空值性

有意识地选择空值性

所有 字段 在 GraphQL 中默认可空，并且在添加新字段到模式时通常是最佳实践接受这个默认行为。然而，在有理由的情况下，不可空字段和 参数（以尾部 ! 表示）是一个重要的机制，可以帮助提高模式的表达性和可预测性。不可空字段也可以对客户端有利，因为它们将确切知道处理 查询 响应时值应返回的位置。当然，不可空字段和参数也有一些权衡，对于模式中的每个类型、字段和参数关于可为空性的每个选择都必须权衡其影响。

计划向后兼容性

空值可能由多种原因引起，如认证失败、数据库错误和/或网络错误。在可能的情况下，应将客户端团队纳入有关模式设计能否为空的讨论中。这有助于他们准备处理空 字段 值的方式，这样就不会影响前端界面用户体验。空值也可以是有效的非错误值。在这些情况下，在字段描述中指出将有助于客户端团队做出明智的决策。

在设计服务模式时，对空值做出明智的决策很重要，但你不可避免地会遇到这种性质的破坏性变更，因为模式自然会演变。当这种情况发生时，GraphOS's 字段使用数据可以让你了解这些 字段在不同 操作和不同客户端中被如何使用。这种可见性将帮助您主动识别问题，并允许您提前与受影响的客户端沟通这些更改，以便他们可以避免意外的错误。

最小化可空参数和输入字段

如前所述，将可空 参数 或输入 字段 对 更新 转换为不可空可能会导致客户端的破坏性更改。因此，指定不可空参数和输入字段在更新中可以帮助你在未来避免这种破坏性更改场景。然而，这样做通常会要求你设计更细粒度的更新，并避免使用填充有可空字段的“除了厨房用具之外的任何东西”的输入类型作为参数，以涵盖所有可能的使用场景。

❌

1
# Two nullable arguments is ambiguous — what happens if we provide both? None?
2
type Query {
3
  user(id: ID, username: String): User
4
}

✅

1
# Separate fields with non-nullable arguments is clearer, and it's easier to
2
# evolve because converting a non-nullable argument to nullable is not a
3
# breaking change.
4
type Query {
5
  userById(id: ID!): User
6
  userByUsername(username: String!): User
7
}

这种方法还增强了模式的整体表达能力，并通过可观察性工具更透明地说明 参数 对整体性能的影响（这尤其适用于查询）。更重要的是，它还将消费者猜测需要包含在 突变 中以实现所需结果的 字段 的负担转移。

当您使用可空的 参数 和 输入 字段时，作为一个额外的提示，考虑提供一个默认值，通过使默认行为更加透明来提高模式的整体表达能力。在这个例子中，我们可以通过向相应的 ProductType 枚举添加一个 ALL 值并将其默认值设置为 ALL 来改进 type 参数。因此，我们不再需要在参数的描述字符串中提供具体关于此行为的说明：

1
type Query {
2
  "Fetch a paginated list of products based on a filter."
3
  products(
4
    # ...
5

6
    "Filter products based on a type."
7
    type: ProductType = ALL
8
  ): ProductConnection
9
}
10

11
enum ProductType {
12
  ALL
13
  BOOKS
14
  MOVIES
15
}

权衡非空实体引用的影响

当向模式添加通过第三方 数据源 解析的字段时，传统建议是考虑到请求可能失败或数据源可能未预先通知就做出破坏性更改，因此这些字段应该是可空的。由于图中许多实体可能由不在服务直接控制中的数据源支持，因此联合 图 为这些考虑因素增加了一个有趣的维度。

是否应在子图模式中使引用实体为可空，这将取决于您现有的架构和内部SLA，并且可能需要逐案评估。请记住，可空性对错误处理的影响——特别是当一个非空字段无法解析时，null结果会向上冒泡到最近的可空父级——考虑在没有成功请求实体时，是部分结果更好还是没有结果更好。