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

我从事的一个项目使用一个GraphQL模式将RESTAPI中的数据公开给各种客户机。模式设计由前端团队“拥有”，并被塑造成代表他们所看到的宇宙。这将UI与API层巧妙地分离，并且工作得相当好。 一些（设计拙劣但必不可少的）API相对复杂，需要领域知识（又称业务逻辑）将数据组合成映射到UI模式的形式，但随着遗留API的分离和重写，业务逻辑正在发生变化-因此问题有两个方面：

我们在填充GraphQL查询响应的解析器中有不需要的业务逻辑

当API团队生成其服务的新版本并希望调用它时，UI团队不一定准备好更新其解析程序以调用它

我正在考虑引入第二个GraphQL实例作为域模型，它将由API团队拥有，并抽象出如何调用每个API的细节，以及如何组合UI模式使用的原始数据。它确实会带来较小的性能开销，但从有利的方面来看，它将模式与API实现细节分离

---

在研究这种方法的过程中，我没有发现在其他地方尝试过这种方法的例子，所以我想知道我是否遗漏了任何例子，或者这是否代表了一种应该避免的反模式

您的附加层似乎可以解决问题，但不能解决根本问题

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

目前拥有业务逻辑和内部API的团队显然是UI团队的上游（如Vernon的实现DDD中所定义的），这很好。但是，API变更需要积极沟通，在这些情况下，API可能需要版本控制

GraphQL毕竟应该是API网关的一个实现细节，因此，即使您不打算更改它，它也应该可以被下一个很酷的东西替换

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

---

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

如果不更好地了解您的组织工作流程，就很难提出支持或反对这种方法的建议。这类问题可以通过改善团队之间的沟通和协作以及改变处理部署的方式来解决。如果是这样的话，那么你最好先这样做，然后进行代价高昂的重构，这也会增加开销和复杂性。如果团队发布了对其API的更新，那么它应该可以在不同的（版本化的）端点下使用，并且旧版本应该仍然可以在以前的端点上使用。这为您的其他开发人员提供了一个时间窗口，以便在不发生任何中断的情况下赶上他们的解析器。您维护的版本数量和持续时间将由所有相关人员共同决定。如果没有类似的内容，即使使用中间API层，您仍然会遇到问题，因为新的中间层仍将被破坏，直到可以更改这些解析程序以匹配对其余端点的更改。同样的问题，你刚刚改变了背景。