Merging GraphQL Queries Together

[theorygeek]

For those of use who use Relay, we sometimes encounter N+1 node queries:

query {
  node(id: "...") { ... }
}

Relay might execute hundreds of these queries at once. For example, you might be displaying a table of data on the page, and maybe the user is able to add a new column. Relay might fetch the data for the new column for each row individually.

I wrote helper for GraphQL that can take these queries and combine them together. You can check it out here: https://gist.github.com/theorygeek/85b2f7df6931a0eb3f06141ef1e57f30

Example usage:

query_1_text = "..."
query_2_text = "..."
query_1_vars = {}
query_2_vars = {}

merged = GraphQL::Language.merge_queries(
  [query_1_text, query_2_text],
  [query_1_vars, query_2_vars]
)

# Returns an array of responses, in the same order as the queries you provided
result = merged.execute(YourSchema, context: your_context)

So I thought I'd ask for some feedback:

• Would it be useful for this to be part of the gem's codebase?
• Any problems (or other feedback) with how it's implemented?

One particular challenge is merging queries that specify different operations (eg, a mutation with a query). And I'm not really sure the impact on subscriptions, @defer, @stream, etc.

[rmosolgo]

I really like the idea of providing some support for "messing" with queries! It's possible to do for people who learn the AST classes, but that's a lot to ask of someone. Besides that, I think some AST-based operations implemented in library externals could be extracted to public (or at least reusable) units of code.

Here are some things I can think of:

• Merging multiple queries into one (as described here)
• Splitting operations out of a collection of definitions (already implemented by this library)
• Resolving fragment dependencies (implemented in StaticValidation and InternalRepresentation, and in the typecheck branch)
• Adding type information to a query (implemented in TypeStack, requested in some capacity for graphql-client)
• Programmatically changing selections sets (I think graphql-client adds __typename in some cases)
• Asserting the validity of a document apart from a GraphQL::Schema (eg, names are unique, fragments don't form cycles) implemented in typecheck branch, I think graphql-client could benefit from that.

I want to brainstorm any other foreseeable uses of the AST and try to find a framework for covering them. (But I also suspect that, when the tools are available, people will find cool new ways to use them!)

ps @josh this might be relevant to your interests!

[junosuarez]

This is something that is handled well by the loader pattern used in graphql-batch

[rmosolgo]

Hmm, I know how to use graphql-batch for fields inside the same operation, but how can you use it for for multiple operations?

[junosuarez]

I don't think it would work out-of-the box with graphql-batch, due to the execution strategy, but the pattern of breaking out execution into two phases, one where you accumulate a bunch of ids to be loaded, and a second where you batch-load all of them efficiently, would apply. It seems safer than trying to modify the query AST.

[rmosolgo]

I was just talking to benwilson512 ("the Absinthe guy") about this issue. He said he handles it with basically an API like:

Schema.execute(
  [query_1, variables_1],
  [query_2, variables_2],
  [query_3, variables_3],
)

Then, the three queries are resolved within the same batching scope, as jsdnxx suggested above.

That sounds like a really nice solution to this issue!

[jrhicks]

I achieved MultiQuery execution using @theorygeek's Query Merging gist mentioned above. I like the API proposed by rmosolgo and benwilson512 above. I hope the documentation and implementation avoid using the term "batching" as this term is starting to feel a little overloaded to me and confuses the similarities and differences with graphql-batch.

[rmosolgo]

Taking a crack at it in #691

[rmosolgo]

This will be included in 1.6.0 as Schema.multiplex(queries) via #691, hoping to release later this week!