Feature request: batchOperations

[reggi]

From Lee's talk at React Eurpoe batch was mentioned as an experimental feature.

I'm curious when / if it's ever going to land in this project or if there's a plugin available today.

[stubailo]

Sounds like all of this stuff would be implemented very easily in the web server itself, except for the @export directive. Although, you could relatively easily use the tools in graphql-js to traverse the AST after your get the result to extract the relevant fields.

So this is something someone could do as a plugin for either express-graphql or apollo-server with a little bit of work, to test it out - I'd say that would be the right way to start rather than adding it to the core implementation here right away.

If you're interested in working on this, I can help you find the right tools to implement it.

[helfer]

@reggi Apollo Server already has a way to send a batch of queries, the only thing it's missing is the @export directive. If you're interested in doing some work in the direction of adding that feature, I'd be more than happy to help you with it!

[leebyron]

This style of dependent batched query isn't supported yet and is not yet a priority relative to some of the other work happening now.

I'm happy to leave this issue open for future consideration though.

[reggi]

Thanks All! I'm excited for this feature, but It's not something I need right now. Would be super nice for testing.

[morris]

Would it be feasible to request

feed {
  stories {
    id
    actor
    message
  }
}

and

feed {
  stories {
    id
    comments {
      actor
      message
    }
  }
}

in parallel and then merge client-side based on story id? The server could cache the work done for feed { stories { id } } briefly and reuse it in the other request. It would be two parallel requests so we wouldn't have to wait for two full round-trips. With HTTP/2 it's also only one connection.

Just a quick thought - felt it's worthwhile to think about a solution that does not require API/language changes.

[alankent]

Another possible use case is for mutations. Take the output of one mutation to create an object A and pass the id allocated into a field for object B. Then you can create multiple objects in a single call, linking them together. The same @export annotation could be used and mutations are already sequential, so sounds not too hard...

[terencechow]

Is this a priority yet? I see a PR here: graphql-python/graphql-core#99

Seems like a natural extension to allow sequential processing that is dependent on previous queries / mutation.

My use case, and I suspect anyone who has ever dealt with a relational db (ie. a huge use case) is that people who want to create multiple dependent relationships in one query:

mutation createClientAndAccount($clientDetails: ClientInput, $accountDetails: AccountInput ){
    createClient(input: $clientDetails) {
        id: (@export as clientId)
    },
    // account is a table that has a foreign key to client, ie a clientId
    createAccount(input: $accountDetails, clientId: $clientId) {
        ....
    }
}

Currently this type of functionality is handled in a resolve function. However that seems totally unnecessary if the language can handle this type of sequential processing. We already know mutations happen sequentially, so theoretically under the hood, even before createAccount is called, we know that somewhere graphql already has the clientId. Ergo, it makes sense to allow a sequential query to be called with the response data there.

[aecepoglu]

Has anyone been working on @helfer 's suggestion? ie. Implementing this as a standalone directive?
I could spare some time for it if nobody else is up for the challenge.

[shtse8]

Any updates? I want to do the same thing but i seems the current release doesn't support this feature.

[OlegIlyenko]

FYI, recently I added batch executor in Sangria:

http://sangria-graphql.org/learn/#batch-executor

It implements all of the functionality described in the talk, including @export directive and (optional) variable inference. Turns out that @export directive is quite non-trivial to implement, mostly because one needs to construct the full dependency graph between queries, analyze cyclic dependencies, etc.

Still collecting the feedback from the users. Hopefully, at some point, I will have enough info to share an update (pros/cons based on the user feedback).