我们正在将一些API移至graphql，并且想知道如何处理已部署的程序包（架构）的回滚以及最佳实践。
更具体地说，假设我们有一个带有3个字段的Schema S，然后添加了第四个字段“ A”。现在由于某种原因，我们无法继续使用该软件包和字段“ A”。因此，我们必须执行该程序包的回滚，以便现在该架构没有字段“ A”。
现在，某些消费者可能会要求此字段“ A”，并且他可能会遇到错误。我们当然可以要求我们的客户进行更新，但是在一段时间内我们可能会失败请求。
我们如何处理这种情况，特别是在几个小时或一天之内进行紧急回滚？
答案 0 :(得分：1)
通常，应避免在没有警告的情况下删除字段，以避免出现您所描述的确切情况。
随着模式的发展，不再需要某些字段的情况并不少见。例如，我们可能不会选择对特定字段进行大幅更改（从可为null的返回类型变为不可为null的返回类型，添加必需的参数等），而是选择添加另一个字段并鼓励客户过渡到使用该字段代替。在这种情况下，我们最终希望删除原始字段。最安全的方法是先弃用该字段。使用SDL，我们可以使用指令来实现：
fieldA: String @deprecated(reason: "Use fieldB instead!")
一段时间后，您可以完全删除该字段。您等待删除字段多长时间取决于您的团队以及您对处理不赞成使用的字段的沟通期望。例如，您可能会发现设置截止日期会有所帮助，届时所有客户端均应停止使用任何不赞成使用的字段。只要您的客户团队拥有处理此类技术债务的带宽，此方法就很好。
可以将已弃用的字段的解析程序更改为返回空值（如果字段本身可为空）或一些最少的模拟数据。这样可以避免进行不必要的API或数据库调用，同时仍然确保客户端请求不会导致错误。
对于您的问题，这意味着您应该避免回退到以前的版本，而应遵循上面概述的要删除字段的过程。
或者，您可以考虑版本控制。 GraphQL通常避开版本控制的概念。如官方网站所述：
为什么大多数API版本？如果对从API端点返回的数据的控制有限，则任何更改都可以视为重大更改，并且重大更改需要新版本。如果要向API添加新功能需要新版本，则需要在频繁发布和具有多个增量版本与API的可理解性和可维护性之间进行权衡。
相比之下，GraphQL仅返回显式请求的数据，因此可以通过新类型和这些类型上的新字段添加新功能，而无需进行重大更改。这导致了一种通常的做法，即始终避免破坏更改并提供无版本的API。
考虑到这一点，通过提供来自不同端点的不同模式来仍然使用GraphQL实现版本控制也是可行的。尽管走这条路线成本高昂且通常不必要，但对于您和您的团队而言，这可能是正确的解决方案，尤其是如果您希望将来必须进行类似的回滚。
答案 1 :(得分：0)
使用GraphQL不能执行任何操作。由于您需要在GraphQL类型系统中显示该字段。可能有可用的库，这些库使您可以指定查询中是否存在字段应该。但是，无法在查询中允许不存在的字段。
但是您可以选择 Blue-Green 部署策略。在此策略中，您需要同时运行两个版本。
让我们说：绿色是具有字段A的版本 ，而蓝色是没有字段A的版本。因此，当您的客户更新时，他们开始请求 Blue 版本。并且一旦您的所有客户都更新，请关闭绿色（带有字段A的 ）。