为什么 TYPE_ADDED_TO_INTERFACE 被认为是一个重大变化？答案

【问题标题】：Why is TYPE_ADDED_TO_INTERFACE considered a breaking change?为什么 TYPE_ADDED_TO_INTERFACE 被认为是一个重大变化？
【发布时间】：2019-06-06 06:47:45
【问题描述】：

我正在使用 GraphQL 的 Apollo 服务器实现，以及 Apollo 引擎，特别是检查模式差异是否包含任何重大更改的功能。我想更好地理解为什么 TYPE_ADDED_TO_INTERFACE 被认为是一个重大变化，如果有人可以提供一个 graphql 查询的例子会因此而中断？

我正在使用apollo/2.9.0 darwin-x64 node-v10.10.0 通过apollo service:check 命令执行架构检查。

例如，如果我有这个架构：

interface Animal {
  id: ID
}

type Dog implements Animal {
  id: ID
  favoriteToy: String
}

然后将其添加到架构中：

type Cat implements Animal {
  id: ID
}

这被认为是一项重大更改。为什么？

我可以看到，如果有人对所有 Animal 对象进行查询，并且在查询中有一个 ... on Dog 片段，他们将开始仅返回带有接口字段的 Cat 对象，直到他们也添加一个... on Cat 片段。这算不算破？

【问题讨论】：

标签： graphql apollo-server

【解决方案1】：

让一个类型实现一个它以前没有实现的接口不应该破坏现有的查询。就您而言，即使省略了内联片段，结果仍然有效（如果未选择接口字段，它们可能会导致返回一个空对象，但这仍然是一个有效的响应）。

但是，我可以预见这种变化会导致特定客户出现问题。例如，在使用 Apollo 客户端时，我们经常会创建一个IntrospectionFragmentMatcher，专门帮助客户端正确缓存来自 union 或 interface 字段的结果。

为了支持联合和接口上的结果验证和准确的片段匹配，可以使用称为 IntrospectionFragmentMatcher 的特殊片段匹配器。如果您的架构中有任何与联合或接口类型相关的更改，您将必须相应地更新片段匹配器。

换句话说，以这种方式更改架构可能会破坏客户端缓存行为。我怀疑对于像apollo-android 这样进行基于模式的代码生成的客户端，这也可能导致一些运行时异常。

【讨论】：