[Capricorn2481]

> Typically you write resolvers with only one level of joins/nesting and then let the query engine do the rest. so e.g. instead of writing a resolver that returns something like `{:person/pet {:pet/id 1, :pet/toys [{:toy/id 2, ...}, ...]}}`, you would have one resolver that returns `{:person/pet {:pet/id 1}}` and then another resolver that takes a pet ID and returns `{:pet/toys [{:toy/id 2}, ...]}` etc.

> So there is a trade-off here in that e.g. you may end up running multiple database queries even though you could've stuffed everything you need into a single database query. That is mitigated by batch resolvers at least so you don't get N+1 query problems

This is the crux of my issue, and batch resolvers don't solve all of it. Batch resolvers solve cases where you need multiple iterations of the same query with different inputs. But in your example, that's two different resolvers that were broken down into atomic units. From what I understand, batch resolvers don't help with that. You need to write a third resolver that can get the outputs of both.

And in that case, it would be nice to have a query planner that can, at the very least, see that a single query could be done with 1 resolver and not two.

[jacobobryant]

yep, so if it's important for the application you're working on that you always run the minimum number of database queries possible, biff.graph isn't a good fit. Pathom's query planner might work as you've described; I'm not sure.