GraphQL: Nested queries vs root queries
I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.
Let's examine both in this example where the current user, me, has many invitations.
Root queries
me {
id
name
}
invitations {
id
message
}
The resolver for invitations returns invitations for the current user.
Nested query
me {
id
name
invitations {
id
message
}
}
These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.
What is the recommended way to design GraphQL queries?
graphql apollo
asked Jan 3 at 17:06
nomadodanomadoda
480316
add a comment |
I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.
Let's examine both in this example where the current user, me, has many invitations.
Root queries
me {
id
name
}
invitations {
id
message
}
The resolver for invitations returns invitations for the current user.
Nested query
me {
id
name
invitations {
id
message
}
}
These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.
What is the recommended way to design GraphQL queries?
graphql apollo
asked Jan 3 at 17:06
nomadodanomadoda
480316
add a comment |
I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.
Let's examine both in this example where the current user, me, has many invitations.
Root queries
me {
id
name
}
invitations {
id
message
}
The resolver for invitations returns invitations for the current user.
Nested query
me {
id
name
invitations {
id
message
}
}
These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.
What is the recommended way to design GraphQL queries?
graphql apollo
asked Jan 3 at 17:06
nomadodanomadoda
480316
I'm using Apollo GraphQL on my server, and I'm trying to design my GraphQL API. One question I'm having is whether I should prefer nested queries over root queries or not.
Let's examine both in this example where the current user, me, has many invitations.
Root queries
me {
id
name
}
invitations {
id
message
}
The resolver for invitations returns invitations for the current user.
Nested query
me {
id
name
invitations {
id
message
}
}
These should achieve the same result, except invitations being nested in the user object me using the latter approach. My concern is though if this works smoothly with Apollo Client in keeping the cache consistent.
What is the recommended way to design GraphQL queries?
graphql apollo
graphql apollo
asked Jan 3 at 17:06
nomadodanomadoda
480316
asked Jan 3 at 17:06
nomadodanomadoda
480316
asked Jan 3 at 17:06
nomadodanomadoda
480316
asked Jan 3 at 17:06
nomadodanomadoda
480316
asked Jan 3 at 17:06
nomadodanomadoda
480316
480316
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.
So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.
edited Jan 4 at 8:59
xwlee
623721
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
add a comment |
I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.
As a rule of thumb, it's better to think about consuming that API, not providing it.
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
add a comment |
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%2f54026744%2fgraphql-nested-queries-vs-root-queries%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.
So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.
edited Jan 4 at 8:59
xwlee
623721
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
add a comment |
One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.
So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.
edited Jan 4 at 8:59
xwlee
623721
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
add a comment |
One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.
So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.
edited Jan 4 at 8:59
xwlee
623721
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
One of the GraphQL selling point is to allow client to have very much flexibility to define the shape of the data they want to query in a minimised number of requests. They also encourage developers to "Think in Graphs" when designing the schema.
So, I would go for nested query which looks more like a graph. Furthermore, it is much more flexible. If user want to get their user profile data with their invitations, they can get them in a single request only. If they only want to get the profile data, they just ignore the invitation part in the query and server will not waste any resources to get the invitation data due to the design nature of the GraphQL.
edited Jan 4 at 8:59
xwlee
623721
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
edited Jan 4 at 8:59
xwlee
623721
edited Jan 4 at 8:59
xwlee
623721
edited Jan 4 at 8:59
xwlee
623721
623721
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
answered Jan 3 at 17:34
Ken ChanKen Chan
41.4k1596114
41.4k1596114
add a comment |
add a comment |
I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.
As a rule of thumb, it's better to think about consuming that API, not providing it.
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
add a comment |
I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.
As a rule of thumb, it's better to think about consuming that API, not providing it.
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
add a comment |
I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.
As a rule of thumb, it's better to think about consuming that API, not providing it.
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
I'd say it really depends on the case. Personally, I treat nested properties as a context: if the API consumer wants to fetch mine notifications, then it's me { notifications { ... } }, not notifications { ... }. If it makes sense to have a top-level key, for example, there's a concept of global notifications (not user-dependent), then go for it. If every user has own notifications (which I assume is true), then me of type User should have it, as every User does. Such generalization encourages reusable thinking: an admin panel, where user(id: ...) { ... } is being used instead of me { ... }, can use the same UI code for free.
As a rule of thumb, it's better to think about consuming that API, not providing it.
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
answered Jan 6 at 21:33
Radosław MiernikRadosław Miernik
2,49132432
2,49132432
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%2f54026744%2fgraphql-nested-queries-vs-root-queries%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
