在GraphQL API中构建查询和类型图结构时，您会在哪里放置仅适用于查看器的高度上下文查询？
在顶层（query.friendRequests）
这将消除User实体中的干扰，并且仅将对所有用户都可查询的查询保留在该实体中。不只是观看用户。 它将添加更多的顶级查询，从而使他们有可能成为特定事物的专家，而这实际上并不是在以图形方式思考和围绕业务逻辑模型数据的思想。
在查看者实体上（query.viewer.friendRequests）
从数据角度来看，将其放在查看器实体（这是一种用户类型）的下方更有意义。好友请求始终属于始终是用户的父对象。
其他示例
你们对此有何想法？在API实施中查看不适用于其他用户实体的用户上下文查询时，遵循的最佳最佳做法是什么？
答案 0 :(得分：0)
我们一直将其放在 Query 中的特定字段下。首先，我们从一个me查询开始，该查询将返回一个用户。但这并不太实用，因为用户类型很大，而且大多数字段不需要整个用户对象，而只需要用户的ID。在您的示例中，我们将执行两个查询
SELECT * FROM account WHERE id = $id
SELECT * FROM friend_request WHERE account_id = $id
除非我们会在me查询中查询一个琐碎的字段，否则第一个查询完全被浪费了。
那我们从李·拜伦那里得到了this thread and especially this answer的启发
查看器是我们在FB到处使用的功能，因此它与我息息相关。此外，查看者不是用户，而是验证会话-引用用户。因此，术语之间存在有用的区别。
现在，我们有一个viewer查询，它返回一个Viewer对象。然后，该对象具有字段user以查询实际的用户对象。这也可能有助于解决problem around private and public fields on your user object。