Batch query operations

[dead-claudia]

This is a restricted version of #375.

I have this giant thing I was looking at doing with GH's GraphQL API, but I ran into a stumbling block: I would need to issue a single request for each set of values rather than just reusing the query and plugging each variable in appropriately.

Instead, could we allow something like this: {"query": "...", "variables": [...]}, returning an array of "data" results rather than a single "data" object? Instead of "variables" being a single object, it's specified as an array of objects, where each entry is itself a standard variables object. This doesn't go as far as enabling variable dependencies like in #375, but it does allow a broad degree of batching that can be (and already is) optimized to death by database engines and other querying engines.

Server-side, this could be merged into a single tree with the parameters as array views at each position. This enables a broad array of potential optimizations without much cost.

[leebyron]

Couldn't we argue that this is a limitation of that schema rather than a limitation of GraphQL itself?

That is, ideally the GH schema exposes a top level field that accepts an array of values for performing a series of parallel requests.

[mathstuf]

IMO, that's like asking why filter() is necessary since the predicate could just instead take an array and return an array instead of operating on each item. Updating every endpoint to accept an array is a huge burden on both sides (plus, what does it mean for multi-input query fields? zip or cross_product?). There'd be no way to ask something like:

query {
  repository(owner: $owner, name: $name) {
    pullRequest(number: $id) {
      id
    }
  }
}

for foobar/baz#3 and foobar/quux#4 with array parameters in one query.

[leebyron]

That’s fair.

I’ve left this open as an alternative strawman to #375, but my prediction is that the community will want a batch executor to handle more desired usecases than parallel execution.

[mathstuf]

Hmm, #375 looks sort of orthogonal to this to me. #375 seems to support dependencies between each query and results of one being inputs of the next. This issue asks for the ability to give multiple input sets for any given query (even if it is multi-stage like in #375). For the given example, how would that issue help given that I don't have output → input flow between the two queries (and that there is again the "must have N literal queries for N input sets" issue even with the other issue being resolved).

[cruhl]

In lieu of a specification solution to this problem, how have others solved it in practice?

[mathstuf]

Personally, I've just made the input arrays in the surrounding code and made the required number of GraphQL queries.