Finding the right Batching Mechanism about composite-schemas-spec HOT 6 OPEN

Variable batching would probably be the best approach and it was actually proposed as an addition to the GraphQL spec a while back (#517). That being said even if it is accepted as part of the official spec it would take a while for a wide adoption... as such I think the only viable option* is the alias batching.

*many frameworks do support request batching but since it is not part of an official spec, I'd imagine there are still quite a few servers might not support it.

from composite-schemas-spec.

Variable batching gets my vote; definitely feels the most GraphQL-y; and for people who use DataLoaders on context already they just need to share the context across the multiple queries and executing them in parallel should have minimal overhead.

from composite-schemas-spec.

My take on batching non-unique operation bodies.

When multiple operations are batched together, there is a risk. Fetching 'Bar' consumes 2s, while 'Foo' is optimized and only takes 90ms.
In such cases, the overall time required for the batched operations will be determined by the slowest one.

While this is true for all types of batching, enforcing a single operation body helps minimize the impact, as the execution flow is likely to be consistent for all variables.

We could stream the response of each execution, but I don't think it will improve performance of a gateway, as every batched operation is most likely required to resolve first, before resolving the next step of a query planner.

from composite-schemas-spec.

As you mentioned, only the Alias Batching option is compatible with existing GraphQL servers.

Opting for any alternative method forces the gateway to be aware about which GraphQL servers support this method and it may become challenging.
Either the schema says "I'm compatible with X" (I'd prefer this option) or the GraphQL server (requires some form of "introspection" and becomes a mess when you deal with multiple instances or gradual deployments).

IMO Variable Batching is strongest option here.

We need to make sure it's compliant with GraphQL spec (not graphql-over-http spec).

from composite-schemas-spec.

Variable batching also seems like the best option if we know that we can always execute the same operation and we are only ever selecting one entity but changing the id.

Wouldn't we want to though also support selecting different entities from one subgraph fetch? If we have to resolve 3 Foos but 10 Bars using variable batching would require use to have a nullable entity fetcher, which I suppose could be a requirement, or would it better to scope it per-request?

[
{
  "query": "query getFoo($a: Int!) { foo(a: $a) }",
  "variables": {
      "a": 1
    }
},
{
  "query": "query getFoo($a: Int!) { foo(a: $a) }",
  "variables": {
      "a": 2
    }
},
{
  "query": "query getBar($b: Int!) { bar(b: $b) }",
  "variables": {
      "b": 1
    }
},
]

VS

{
  "query": "query getFooAndBar($a: Int, b: Int) { foo(a: $a) bar(b: $b) }",
  "variables": [
    { "a": 1 }, { "a": 2 }, { "b": 1 }, 
  ]
},

We could also add the option of request AND variable batching

[
{
  "query": "query getFoo($a: Int!) { foo(a: $a) }",
  "variables": [
    {"a": 1 }, {"a": 2 }
  ]
},
{
  "query": "query getBar($b: Int!) { bar(b: $b) }",
  "variables": {
      "b": 1
    }
},
]

from composite-schemas-spec.

I understand that this has much wider implications, but just to put it out there: the source Source Schema 1 could also provide a root field which can be queried likes this:

query($ids: [ID!]! ,$requirements: [ProductDimensionInput!])  {
   ordersDimensions(ids: $ids, dimensions: $requirements) 
}

This would not require any special batching mechanism at all.

from composite-schemas-spec.