GraphQL 中的前向兼容性

Question

GraphQL 因其易于维护用其定义的 API 的向后兼容性而闻名。您应该在每次需要时添加新字段/类型，并且永远不要删除旧字段/类型，只用

@deprecated

指令标记它们。因此，您的服务器可以独立于其客户端版本而发展。

但是，我有一个完全相反的问题：我们有许多独立的服务器，其中一些无法更新，而客户端（可能）可以连接到其中任何一个。因此，当客户端采用 API 类型中的新字段（在某些较新的服务器中引入），然后连接到较旧的服务器时，它将收到错误，因为它将尝试查询该服务器上不存在的字段。

所以问题是：是否有一些已知的方法可以在 GraphQL 中处理此类情况？

我唯一想到的是有一个顶级查询字段，它将返回支持类型的列表，作为字符串列表。因此，每当您想在现有类型

foo

中添加新字段时，只需添加一个新类型

foo2

并将该类型添加到支持的类型列表中即可。因此，客户可以决定它可以使用什么类型，以及相应地它可以显示什么功能。然而，这看起来相当可怕，因为 GraphQL 的图形性质：很难保证 clinet 的查询不会通过某些奇怪的路径到达某些不受支持的类型。

当然，另一个解决方案是仅对整个 API 进行版本控制，并将对架构的任何更改视为不兼容的 API 版本。但这看起来要么太僵硬，要么维护起来太费力。

附注我想，对于这种情况，GraphQL 可能不是一个好的解决方案，但是，正如通常发生的那样，我们在预见这些用例之前就决定使用 GraphQL。

Answer 1

...通常没有“永远无法更新”服务器的状态

如何不影响 REST 服务器？只是以 404 响应

/api/Vxxx

 - 显然不支持新版本？ DX 比 graphQL 更好？我不这么认为。

可能的解决方案：

提供带有一些
• query version

  （+可加载模式）的 API - 要求开发人员在应用程序开始时使用（使用 

  login

   查询）；

在文档中添加“API版本xxx中引入的字段”；
保留支持 API 版本的服务器列表；
某些服务/服务器可查询[最近]具有最低 API 版本 xxx 的服务器。

Answer 2

我对这种方法并不完全满意，但我想出的最好方法是：

有两种（或更多）形式的查询，一种用于较旧的模式，一种用于较新的模式。
查询
• __schema

   元对象以找出哪些成员存在和不存在。

相应地选择正确的查询。

不幸的是，无法使用

@include(if:)

/

@skip(if:)

 指令排除不存在的字段，因为指令是在类型检查后评估的，因此您要么需要多个查询文档，要么使用一些客户端模板来构建它们.