***或查看器类型内的 GraphQL 查看器上下文查询？

Posted 2023-03-08

【中文标题】***或查看器类型内的 GraphQL 查看器上下文查询？

【英文标题】：GraphQL viewer-contextual queries on the top-level or within the viewer type?

【发布时间】：2019-04-24 14:45:08

【问题描述】：

在 GraphQL API 中构建查询和类型图结构时，您会将仅适用于查看器的高度上下文相关的查询放在哪里？

在顶层 (query.friendRequests)

这将消除 User 实体中的噪音，并且只保留可供所有用户查询的查询。不仅仅是观看用户。 它将添加更多的***查询，并有可能成为特定事物的专家，而这并不是真正的图思维和模型数据围绕业务逻辑的想法。

在查看者实体上 (query.viewer.friendRequests)

从数据的角度来看，将其放在查看器实体（这是一个用户类型）之下更有意义。好友请求始终属于始终是用户的父对象。

其他示例

仪表板小部件 用户通知 操作项/TODO 项/任务列表 消息 柜台和徽章

你们对此有何看法？在查看 API 实现中不适用于其他用户实体的用户上下文查询时，最好遵循什么最佳实践？

【参考方案1】：

我们一直把它放在Query中的特定字段下。首先，我们从返回用户的me 查询开始。但这并不是很实用，因为用户类型变得非常大，而且大多数字段不需要整个用户对象，而只需要用户的 ID。在您的示例中，我们将执行两个查询

SELECT * FROM account WHERE id = $id
SELECT * FROM friend_request WHERE account_id = $id

除非我们在 me 查询中查询一个微不足道的字段，否则第一个查询完全被浪费了。

然后我们从 Lee Byron 那里得到了一点this thread and especially this answer 的启发

Viewer 是我们在 FB 随处使用的工具，所以一直困扰着我。此外，查看者不是用户，它是一个身份验证会话——它引用了一个用户。所以有一个有用的术语区别。

现在我们有一个viewer 查询，它返回一个Viewer 对象。然后这个对象有一个字段user 来查询实际的用户对象。这也可能会或可能不会帮助解决problem around private and public fields on your user object。