You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These queries aren't equivalent. GraphQL operates on a layer-by-layer basis, so you have to execute the top layer fields before you can execute their selection sets, so the first query fetches (presumably, the naming is non-obvious) all orders (without limits), then on those it fetches their id and date and the user of the order (for some reason passes the name parameter to it?).
However, your latter query better embraces the graph nature of GraphQL: start at the node you know (in this case, a named user) and then traverse the graph to get the data you need (getting the orders for that user).
This query will return the id of all orders. Querying additional data about each order (e.g. adding more fields in #PLACEHOLDER#) WILL NOT limit the orders returned - you will still get the same list of ids, but now you'll get extra details too.
If you want to limit the orders, you must do that explicitly when you request them:
GraphQL does not perform any filtering itself, it doesn't even understand the concept of filtering. It passes arguments through to your business logic via resolvers; it's up to your resolvers to implement them. E.g. for this you might have that the resolver for allOrders sees the belongingToUsername argument and thus performs a database query such as select * from orders where user_id = (select id from users where username = $1). This is just an example, GraphQL is independent of the data source you're using, doesn't have to be an SQL database.
e.g. in JS you might do something like:
constresolvers={Query: {asyncallOrders(_,args,context){const{ belongingToUsername }=args;const{ databaseClient }=context;constconditions=['true'];if(belongingToUsername){conditions.push(`user_id = (select id from users where username = ${sql.escape(belongingToUsername)})`);}constquery=`select *from orderswhere (${conditions.join(') AND (')});`;returndatabaseClient.fetchRows(query);}}}
Note this is an absolutely terrible resolver, and your resolvers should really hand over to your business logic layer which should perform this logic; I'm just doing this to be helpful to your understanding.
Equally if you're using GraphQL over a REST API your resolver could be something like:
https://discord.com/channels/625400653321076807/631489012632125440/1240171683638153276
These queries aren't equivalent. GraphQL operates on a layer-by-layer basis, so you have to execute the top layer fields before you can execute their selection sets, so the first query fetches (presumably, the naming is non-obvious) all orders (without limits), then on those it fetches their id and date and the user of the order (for some reason passes the name parameter to it?).
A more expected query would be something like:
However, your latter query better embraces the graph nature of GraphQL: start at the node you know (in this case, a named user) and then traverse the graph to get the data you need (getting the orders for that user).
Another way to think of it is:
This query will return the
id
of all orders. Querying additional data about each order (e.g. adding more fields in#PLACEHOLDER#
) WILL NOT limit the orders returned - you will still get the same list ofid
s, but now you'll get extra details too.If you want to limit the orders, you must do that explicitly when you request them:
GraphQL does not perform any filtering itself, it doesn't even understand the concept of filtering. It passes arguments through to your business logic via resolvers; it's up to your resolvers to implement them. E.g. for this you might have that the resolver for
allOrders
sees thebelongingToUsername
argument and thus performs a database query such asselect * from orders where user_id = (select id from users where username = $1)
. This is just an example, GraphQL is independent of the data source you're using, doesn't have to be an SQL database.e.g. in JS you might do something like:
Note this is an absolutely terrible resolver, and your resolvers should really hand over to your business logic layer which should perform this logic; I'm just doing this to be helpful to your understanding.
Equally if you're using GraphQL over a REST API your resolver could be something like:
GraphQL doesn't care which of these vastly different things you do - it's down to what resolver you write.
You could even do something which mixes multiple things together:
Really up to you how you implement your resolvers.
The text was updated successfully, but these errors were encountered: