GraphQL Federation：是否可以让多个服务贡献一个列表/数组结果？
假设我定义了以下 GraphQL 架构：
type Widgets {
id: ID!
name: String!
}
type Basket {
id: ID!
widgets: [Widgets]!
}
并且我有一个提供这些结果的小部件服务。
但现在我有一个新服务“NEW widget”服务，我想为小部件列表做出贡献。因此，小部件服务提供了小部件列表，但“新小部件”服务还有一些小部件要添加到列表中。
这可能吗？
我知道我可以从“新小部件”服务向小部件或购物篮类型添加新字段，但我想知道是否可以将结果贡献到其他服务的列表中。
这可能来自 GraphQL 规范或 Apollo 联盟吗？
Assuming I have the following GraphQL schema defined:
type Widgets {
id: ID!
name: String!
}
type Basket {
id: ID!
widgets: [Widgets]!
}
And that I have a widget service that provides those results.
But now I have a new service "NEW widget" service, that I'd like to contribute to the list of widgets. So the widget service provides a list of widgets, but the "NEW widget" service has a few more widgets to add to the list.
Is this possible?
I know I could add a new field to the Widget or Basket types from "NEW widget" service, but I'm wondering if I can contribute results to a list from another service.
This that possible from the GraphQL spec or Apollo federation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不可能通过推送项目来“扩展”由子图之一解析的列表。唯一允许的“扩展”操作是更新列表的项目，而不是列表本身。
在 GraphQL federation 中，一般规则是可共享字段在语义上是相等的，因此请求子图 A 或子图 B 中的字段应产生相同的响应。无论是 Apollo Federation 规范还是正在开发的 GraphQL 基金会（及其复合模式工作组的努力），规则都是相同的。
这并不意味着该字段总是只解析一次。网关可以多次请求它，每次网关可以要求解析许多子图中的该字段，以解析仅在这些子图中可用的部分内部结构。
It's not possible to "extend" the list resolved by one of the subgraphs, by pushing the items. The only "extend" action that is allowed is to update items of the list, not the list itself.
In GraphQL federation the general rule is that a shareable field is semantically equal, so requesting a field in subgraph A or subgraph B should result in the same response. Whether it is Apollo Federation spec or the one GraphQL Foundation (with its Composite Schema Working Group effort) is developing, the rule is the same.
It does not mean that the field is resolved only once, always. It could be requested by the gateway multiple times, each time the gateway could ask to resolve that field in many subgraphs, to resolve part of its inner structure that is only available in those subgraphs.