我在一个项目中工作，该项目使用单个GraphQL模式将来自REST API的数据公开给各种客户端。模式设计由前端团队“拥有”，其形状可以表示他们所看到的Universe。这将UI与API层巧妙地分离开来，并且运行良好。 一些（设计欠佳但必不可少的）API相对复杂，需要领域知识（又称业务逻辑）才能将数据组成映射到UI架构的形式，但是随着将旧API拆开并重写，业务逻辑正在发生变化。 -因此问题是双重的：
我正在考虑引入第二个作为域模型的GraphQL实例，该实例将由API团队拥有，并抽象出如何调用每个API的详细信息，并组成UI架构要使用的原始数据。确实会带来很小的性能开销，但是从正面来看，这使Schema与API实现细节脱钩。
在研究这种方法时，我没有找到在其他地方尝试过这种方法的示例，因此想知道我是否错过了任何方法，或者这是否代表应该避免的反模式？
答案 0 :(得分：0)
似乎您的附加层可以解决问题，但不能解决根本问题。
如某些评论中所述，解决此问题的最佳方法取决于组织本身。而且，可能需要进行一些组织上的更改以避免疯狂。
当前拥有业务逻辑和内部API的团队显然在UI团队的上游（如Vernon的实施DDD 中所定义），这很好。但是随后，需要积极地传达API更改，在这种情况下，可能需要对API进行版本控制。GraphQL毕竟应该是API网关的实现细节，因此，即使您不打算对其进行更改，它也应该可以被下一个很酷的东西替换。
如果您还需要以需要业务逻辑（甚至更糟的是保持状态）的方式处理数据，因为这种“他们所看到的宇宙”与您从上游获得的信息完全不同；这超出了网关模式，这本身就是一个问题。可以在REST API和网关之间部署一个单独的组件（越小越好），以解决此问题，但是该组件将是一流的公民，而不仅仅是一些粘合代码。该组件/服务提供GraphQL几乎没有好处。它只有一个客户端，即您现有的网关。
如果您的后端REST API仅为UI提供此数据，但UI无法像这样使用它，那么“这是一个人的问题”，需要首先解决。