我们应该使用两个GraphQL层吗？

Question

我在一个使用单个GraphQL模式将REST API的数据公开给各种客户端的项目上工作。模式设计由前端团队“拥有”，其形状可以表示他们所看到的Universe。这将UI与API层巧妙地分离开来，并且运行良好。一些（设计欠佳但必不可少的）API相对复杂，需要领域知识（又称业务逻辑）才能将数据组成映射到UI架构的形式，但是随着将旧API拆开并重写，业务逻辑正在发生变化。 -因此问题是双重的：

1. 解析器中存在填充GraphQL查询响应的有害业务逻辑
2. 当API团队产生其服务的新版本并希望调用它时，UI团队不一定准备好更新其解析程序以调用它

我正在考虑引入第二个作为域模型的GraphQL实例，该实例将由API团队拥有，并抽象出如何调用每个API的细节以及组成UI架构要使用的原始数据。它确实带来了很小的性能开销，但从正面来看，这使Schema与API实现细节脱钩。

在研究这种方法时，我没有找到在其他地方尝试过这种方法的示例，因此想知道我是否错过了任何方法，或者这是否代表应该避免的反模式？

Answer 1

看来你的附加层可以解决问题，但不能解决根本问题。

正如一些评论中提到的，解决此问题的最佳方法取决于组织本身。此外，可能需要进行一些组织变革以避免疯狂。

当前拥有业务逻辑和内部 API 的团队显然位于 UI 团队的上游（如 Vernon 的实施 DDD中所定义），这很好。但是，API 更改需要主动传达，并且在这些情况下 API 可能需要版本控制。

毕竟，GraphQL 应该是 API 网关的实现细节，因此，即使您不打算更改它，它也应该可以被接下来很酷的东西所取代。

如果您还需要以需要业务逻辑的方式处理数据（更糟糕的是，需要维护状态），因为这个“他们所看到的宇宙”与您从上游获得的完全不同；这超出了网关模式，并且它本身就是一个问题。可以在 REST API 和网关之间部署一个单独的组件（越小越好）来解决此问题，但该组件将是一等公民，而不仅仅是一些粘合代码。该组件/服务为 GraphQL 提供服务几乎没有什么好处；它只有一个客户端，即您现有的网关。

如果你的后端 REST API 只为 UI 提供这些数据，但 UI 不能那样使用它，那么“这是一个人的问题”，需要首先解决。