Apollo / GraphQL Same Query with Different Parameters
How would I go about having an Apollo query with different parameters. Let's say my app has the concept of users and I want my API to be able to find a user either by ID or username.
It doesn't seem I can do this
type Query {
user(id: ID!): User
user(username: String!): User
}
do I have to resort to something like this
type Query {
userById(id: ID!): User
userByUsername(username: String!): User
}
graphql apollo-server
asked Dec 27 '18 at 22:05
Tommy May
533610
add a comment |
How would I go about having an Apollo query with different parameters. Let's say my app has the concept of users and I want my API to be able to find a user either by ID or username.
It doesn't seem I can do this
type Query {
user(id: ID!): User
user(username: String!): User
}
do I have to resort to something like this
type Query {
userById(id: ID!): User
userByUsername(username: String!): User
}
graphql apollo-server
asked Dec 27 '18 at 22:05
Tommy May
533610
add a comment |
How would I go about having an Apollo query with different parameters. Let's say my app has the concept of users and I want my API to be able to find a user either by ID or username.
It doesn't seem I can do this
type Query {
user(id: ID!): User
user(username: String!): User
}
do I have to resort to something like this
type Query {
userById(id: ID!): User
userByUsername(username: String!): User
}
graphql apollo-server
asked Dec 27 '18 at 22:05
Tommy May
533610
How would I go about having an Apollo query with different parameters. Let's say my app has the concept of users and I want my API to be able to find a user either by ID or username.
It doesn't seem I can do this
type Query {
user(id: ID!): User
user(username: String!): User
}
do I have to resort to something like this
type Query {
userById(id: ID!): User
userByUsername(username: String!): User
}
graphql apollo-server
graphql apollo-server
asked Dec 27 '18 at 22:05
Tommy May
533610
asked Dec 27 '18 at 22:05
Tommy May
533610
asked Dec 27 '18 at 22:05
Tommy May
533610
asked Dec 27 '18 at 22:05
Tommy May
533610
asked Dec 27 '18 at 22:05
Tommy May
533610
533610
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I believe your second option is the best however you could do something like this.
type Query {
user(id: ID, username: String): User
}
If the parameters are not required then your resolver could use some logic to determine if it should get the user based on the id or the username.
if (args.id) {
return getUserById(args.id)
} else {
return getUserByUsername(args.username)
}
However for reasons gone over in this talk https://youtu.be/pJamhW2xPYw?t=750 (maybe see at about 12:30), I believe your second option is a better design choice. Hope that helps!
answered Dec 27 '18 at 22:32
jkdowdle
10316
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
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%2f53951318%2fapollo-graphql-same-query-with-different-parameters%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
I believe your second option is the best however you could do something like this.
type Query {
user(id: ID, username: String): User
}
If the parameters are not required then your resolver could use some logic to determine if it should get the user based on the id or the username.
if (args.id) {
return getUserById(args.id)
} else {
return getUserByUsername(args.username)
}
However for reasons gone over in this talk https://youtu.be/pJamhW2xPYw?t=750 (maybe see at about 12:30), I believe your second option is a better design choice. Hope that helps!
answered Dec 27 '18 at 22:32
jkdowdle
10316
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
add a comment |
I believe your second option is the best however you could do something like this.
type Query {
user(id: ID, username: String): User
}
If the parameters are not required then your resolver could use some logic to determine if it should get the user based on the id or the username.
if (args.id) {
return getUserById(args.id)
} else {
return getUserByUsername(args.username)
}
However for reasons gone over in this talk https://youtu.be/pJamhW2xPYw?t=750 (maybe see at about 12:30), I believe your second option is a better design choice. Hope that helps!
answered Dec 27 '18 at 22:32
jkdowdle
10316
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
add a comment |
I believe your second option is the best however you could do something like this.
type Query {
user(id: ID, username: String): User
}
If the parameters are not required then your resolver could use some logic to determine if it should get the user based on the id or the username.
if (args.id) {
return getUserById(args.id)
} else {
return getUserByUsername(args.username)
}
However for reasons gone over in this talk https://youtu.be/pJamhW2xPYw?t=750 (maybe see at about 12:30), I believe your second option is a better design choice. Hope that helps!
answered Dec 27 '18 at 22:32
jkdowdle
10316
I believe your second option is the best however you could do something like this.
type Query {
user(id: ID, username: String): User
}
If the parameters are not required then your resolver could use some logic to determine if it should get the user based on the id or the username.
if (args.id) {
return getUserById(args.id)
} else {
return getUserByUsername(args.username)
}
However for reasons gone over in this talk https://youtu.be/pJamhW2xPYw?t=750 (maybe see at about 12:30), I believe your second option is a better design choice. Hope that helps!
answered Dec 27 '18 at 22:32
jkdowdle
10316
answered Dec 27 '18 at 22:32
jkdowdle
10316
answered Dec 27 '18 at 22:32
jkdowdle
10316
answered Dec 27 '18 at 22:32
jkdowdle
10316
10316
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
add a comment |
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
Thanks for the suggestion. I'm not in love with the answer since I believe it makes the API a little hard to understand from a user perspective. I'm going to leave the question open until tomorrow and I'll accept your answer if no one can provide a better alternative.
– Tommy May
Dec 28 '18 at 2:10
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
According youtu.be/pJamhW2xPYw?t=1169 speaker prefers Tommy's way
– Egor Zaremba
Dec 28 '18 at 3:33
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f53951318%2fapollo-graphql-same-query-with-different-parameters%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
