我正在采用 GraphQL 作为几个后端微服务的数据组合层。我们有一个UserService它提供了一些与用户相关的 REST API，一个是/users的，另一个是/detail?userId=${userId}。 我有以下架构定义：
type User {
userId: ID!
name: String!
address: String
// ... some other fields
}
Query {
users: [User]!
userDetail(userId: ID): User
}
问题是，由于某种性能原因，/users中的User项的字段少于/detail。例如，address字段在列表API 中不存在，仅存在于详细信息API 中。
那么，我们是否必须为列表查询定义另一个UserListItem？由于后端 API 的限制，我们无法在列表和详细信息查询之间共享相同的User类型定义。
首先，我认为我们应该考虑为什么列表 API 中不存在地址字段？
在 Apollo 的视图中，相同的用户 ID 应该得到相同的结果。 所以在你的情况下，这是不合理的。
如果不为列表查询定义其他类型将导致缓存问题(客户端(
您可以参考此文章以获取更多信息
(相同的 ID，键入不同的结果(
https://kamranicus.com/posts/2018-03-06-graphql-apollo-object-caching
如果您为列表查询定义另一种类型也会导致缓存问题(关于突变后客户端更新缓存(
当然，客户端可以通过设置fetchPolicy或手动更新缓存来解决缓存问题，但这不是最好的解决方案。
因此，如果我是后端开发人员，我将尝试将地址字段放在列表 API 中。
如果你真的不能把地址字段放在列表API中，我认为定义另一种类型更好。
但是客户端需要更加注意更新缓存的问题。
例如，如果我们为用户定义另一种类型。(类型UserDetail(
假设我们有一个显示用户列表的页面(类型User(，并且我们有一个用于编辑用户信息的突变。
通常，当我们转到编辑页面时，我们将执行userDetail来初始化表单数据。(类型UserDetail(
如果返回类型在突变后User，则用户列表中的相同 id 将自动更新缓存。
(https://www.apollographql.com/docs/react/advanced/caching/#automatic-cache-updates(
但是当我们回到编辑页面时，你会发现 userDetail 的数据在突变后保持不变，因为突变的返回类型是User而不是UserDetail。
在这种情况下，我将 fetchPolicy 设置为network-only(userDetail 查询(，反之亦然。
相同的 id 和类型，但结果不同
请参阅此文章
https://kamranicus.com/posts/2018-03-06-graphql-apollo-object-caching