2 ms·
No, it can't because it's actually making two separate queries. For example, let's say we're fetching classified ads with the users that posted them. First your
by kevsim 6y ago
No, it can't because it's actually making two separate queries. For example, let's say we're fetching classified ads with the users that posted them. First your GraphQL resolvers would fetch the ads (and you won't know that the users are being asked for). Then for each ad, you'd tell your data loader to fetch the user associated with that add. That will ultimately result in a single SQL query with an IN like `SELECT * FROM users WHERE id IN (?)` where you'd pass in all the user IDs you gathered from the results of the ads query.
However, another commenter pointed out above that some implementations allow peeking into the GraphQL query. That way if you know you're going to need the user anyway, you can already perform the join proactively when you fetch the ads.
In a few cases we've done this because we always want the joined results so we just do the join regardless of the query we get.
- xyzzy_plugh 6y agoErm, are you telling me there is no way to pipeline the ads query to be inline within the IN clause? Because that'd generate a join, generally. I still don't understand why this abstraction is useful, if not harmful.
- kevsim 6y agoI think there is a way to do it, that was the peeking I referred to. But it's not how it works out of the box. I think the abstraction is somewhat useful if your GraphQL queries vary tremendously (one device asks for the user along with the ads, another device doesn't). Expand this out to a bunch of different data types and you'd find yourself writing a lot of variations of the queries. GraphQL with Data loader allows you to write these things exactly once albeit with potentially suboptimal queries. All of that being said, we're finding that our queries vary very little and are somewhat questioning the value of data loaders and of GraphQL altogether in our case.