Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Article: GraphQL basics around filtering and there being no "limiting join" to children #16

Open
benjie opened this issue May 15, 2024 · 0 comments

Comments

@benjie
Copy link
Owner

benjie commented May 15, 2024

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:

query getOrdersWithUser ($name: "sam") {
  allOrders(forUsername: $name) { 
    id
    date
    User { 
     name
    }
  }
}

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).

is graphql smart enough to ...
GraphQL works in a very simple way, resolvers, it's up to your resolvers to be smart. Or use an alternative execution engine that's compatible with GraphQL - you might learn a bit from my talk at GraphQLConf last year: https://www.youtube.com/watch?v=4ao-zjiOGx8&list=PLP1igyLx8foE9SlDLI1Vtlshcon5r1jMJ&index=12

Another way to think of it is:

query getOrdersWithUser ($name: String! = "sam") {
  allOrders { 
    id
    #PLACEHOLDER#
  }
}

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:

query getOrdersWithUser ($name: String! = "sam") {
  allOrders(belongingToUsername: $name) { 
    id
    #PLACEHOLDER#
  }
}

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:

const resolvers = {
  Query: {
    async allOrders(_, args, context) {
      const { belongingToUsername } = args;
      const { databaseClient } = context;
      const conditions = ['true'];
      if (belongingToUsername) {
        conditions.push(`user_id = (select id from users where username = ${sql.escape(belongingToUsername)})`);
      }
      const query = `
select *
from orders
where (${conditions.join(') AND (')});`;
      return databaseClient.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:

const resolvers = {
  Query: {
    async allOrders(_, args, context) {
      const { belongingToUsername } = args;
      const { apiClient } = context;
      if (belongingToUsername) {
        return apiClient.get(`/users/${belongingToUsername}/orders`);
      } else {
        return apiClient.get(`/orders`);
      }
    }
  }
}

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:

const resolvers = {
  Query: {
    async allOrders(_, args, context) {
      const { belongingToUsername } = args;
      const { databaseClient, usersService } = context;
      const conditions = ['true'];
      if (belongingToUsername) {
        const user = await usersService.getUserByUsername(belongingToUsername);
        conditions.push(`user_id = ${sql.escape(user.id)}`);
      }
      const query = `
select *
from orders
where (${conditions.join(') AND (')});`;
      return databaseClient.fetchRows(query);
    }
  }
}

Really up to you how you implement your resolvers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant