添加Enum值是GraphQL的一项重大更改吗？

Question

根据GraphQL最佳实践，GraphQL服务应该遵循“总是避免中断更改和提供无版本API的常见做法”。

向Enum添加值是否被认为是如果遵循最佳实践就应该避免的重大更改？

为了说明这一点，让我们假设模式具有这样的枚举：

enum Episode {
  NEWHOPE
  EMPIRE
  JEDI
}

在将来的某个时候，把这个枚举演化成这样是不好的做法吗？

enum Episode {
  NEWHOPE
  EMPIRE
  JEDI
  FORCEAWAKENS
  ROGUEONE
}

Answer 1

TLDR:向枚举添加值被认为是“潜在的危险更改”。

根据规范(http://spec.graphql.org/October2021/#sec-Validation.Type-system-evolution)

任何可能导致先前有效的请求无效的更改都被视为破坏更改。

我试图找到一个决定性的改变列表，这比我预期的更困难。在graphql中，似乎既有“破坏更改”的概念，也有“危险更改”的概念，它们共同响应了两个函数findBreakingChanges和findDangerousChanges。这个PR：https://github.com/graphql/graphql-js/pull/701#issuecomment-277851631推荐添加findDangerousChanges，因为有些更改不符合规范中“破坏”的定义，它们仍然是“潜在的危险”。根据代码，向枚举添加值被认为是“潜在危险的更改”：https://github.com/graphql/graphql-js/blob/40ff40a21c710372330e65f0fb58f13c2df92a77/src/utilities/findBreakingChanges.ts#L37-L63

• ( findBreakingChanges - https://github.com/graphql/graphql-js/blob/a24a9f35b876bdd0d5050eca34d3020bd0db9a29/src/utilities/findBreakingChanges.ts#L79)
• findDangerousChanges - https://github.com/graphql/graphql-js/blob/a24a9f35b876bdd0d5050eca34d3020bd0db9a29/src/utilities/findBreakingChanges.ts#L93

Answer 2

具体来说，中断的更改是对模式结构的更改，会导致已经写入的查询失败。我无法在网上找到详尽的列表，但以下是几个打破更改的示例：

• 从对象类型中删除字段(使用该字段的查询将变得无效)
• 向字段中添加必需的参数(使用没有该参数的字段的查询将变得无效)
• 当新类型不是旧类型的超级类型时，更改字段的返回类型(例如，从Int更改为String，使用该字段的客户端可能有来自新响应的类型错误)。

一个新的枚举值可能会破坏一个客户机(如果它没有处理新情况的代码，它可能有一个运行时错误)，但我认为这是一个客户机设计问题，但不是对模式的破坏！