GraphQL：嵌套查询与根查询答案

【问题标题】：GraphQL: Nested queries vs root queriesGraphQL：嵌套查询与根查询
【发布时间】：2019-05-30 07:20:02
【问题描述】：

我在我的服务器上使用 Apollo GraphQL，并且我正在尝试设计我的 GraphQL API。我遇到的一个问题是我是否应该更喜欢嵌套查询而不是根查询。

让我们在这个例子中检查一下当前用户me 有很多invitations。

根查询

me {
    id
    name
}

invitations {
    id
    message
}

invitations 的解析器返回当前用户的邀请。

嵌套查询

me {
    id
    name
    invitations {
        id
        message
    }
}

除了使用后一种方法将邀请嵌套在用户对象me 中之外，这些应该可以实现相同的结果。我担心的是，如果这与 Apollo 客户端在保持缓存一致方面顺利工作。

设计 GraphQL 查询的推荐方法是什么？

【问题讨论】：

标签： graphql apollo

【解决方案1】：

我会说这真的取决于具体情况。就个人而言，我将嵌套属性视为 context：如果 API 使用者想要获取 mine 通知，那么它是 me { notifications { ... } }，而不是 notifications { ... }。如果有一个顶级键有意义，例如，有一个 global 通知的概念（不依赖于用户），那么就去吧。如果每个用户都有自己的通知（我认为这是真的），那么User 类型的me 应该有它，就像每个User 一样。这种概括鼓励了可重用的思维：使用user(id: ...) { ... } 而不是me { ... } 的管理面板可以免费使用相同的 UI 代码。

根据经验，最好考虑使用该 API，而不是提供它。

【讨论】：

【解决方案2】：

GraphQL 的卖点之一是允许客户非常灵活地以最少的请求数量来定义他们想要查询的数据的形状。他们还鼓励开发人员在设计模式时使用“Think in Graphs”。

所以，我会选择看起来更像图表的嵌套查询。此外，它更加灵活。如果用户想通过他们的邀请获取他们的用户配置文件数据，他们只能在一个请求中获取它们。如果他们只想获取个人资料数据，他们只是忽略查询中的邀请部分，并且由于 GraphQL 的设计性质，服务器不会浪费任何资源来获取邀请数据。

【讨论】：