0

When building the query and type graph structure in a GraphQL API, where would you put highly contextual queries that only apply to the viewer?

On the top-level (query.friendRequests)

This would remove noise in the User entity and only keep queries in there that are queryable for all users. Not just the viewing user. It would add much more top-level queries with a risk of them becoming specialists in specific things which is not really thinking-in-a-graph and model-data-around-business-logic ideas.

On the viewer entity (query.viewer.friendRequests)

From a data perspective, this makes more sense to put it underneath the viewer entity (which is a User type). friend requests always belong to a parent object which is always a user.

Other Examples

  • Dashboard widgets
  • User notifications
  • Action items / TODO items / Task lists
  • Messages
  • Counters and badges

What are you guys' thoughts on this? What would be a good best-practice to follow for viewing user contextual queries that don't apply to other user entities in an API implementation?

1 Answers1

0

We have always put it under a specific field in Query. First we started with a me query that would return a user. But this did not turn out very practical because the user type got very big and also most fields did not need the whole user object but only the user's ID. In your example we would have done two queries

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

Unless we would query a trivial field on the me query the first query was completely wasted.

Then we got inspired a bit this thread and especially this answer from Lee Byron

Viewer is what we used everywhere at FB, so it’s stuck with me. Also, a Viewer is not a User, it’s an Auth session - which references a User. So there’s a useful distinction of terms.

Now we have a viewer query that returns a Viewer object. This object then has a field user to query the actual user object. This also might or might not help solving the problem around private and public fields on your user object.

Herku
  • 7,198
  • 27
  • 36