GraphQL viewer-contextual queries on the top-level or within the viewer type?
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?
graphql api-design
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
add a comment |
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?
graphql api-design
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
add a comment |
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?
graphql api-design
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
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?
graphql api-design
graphql api-design
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
asked Nov 21 '18 at 23:56
Sarah HenkensSarah Henkens
1
1
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422098%2fgraphql-viewer-contextual-queries-on-the-top-level-or-within-the-viewer-type%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
add a comment |
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.
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
add a comment |
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.
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
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.
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
answered Nov 22 '18 at 9:44
HerkuHerku
2,290712
2,290712
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53422098%2fgraphql-viewer-contextual-queries-on-the-top-level-or-within-the-viewer-type%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
