We've come across a situation where query (and mutation) batching would be very useful. I noticed that this was an issue in the Android project but not in the iOS one so I wanted to add a reference here.
Thanks! Once https://github.com/apollographql/apollo-ios/pull/186 lands that should make it easier to add support for query batching.
Out of curiosity, what is your use case? Especially with HTTP/2, query batching doesn't seem to have that many performance benefits and may actually degrade performance.
We'd like to use it to pass _n_-mutations in a set order. Our specific use case is the removal of _n_ items in a hierarchical list (where you can't remove the parent before the children are removed) in one go. An example for a mutation like this could be:
mutation {
child1: remove(id: "2"){ id }
child2: remove(id: "3"){ id }
child3: remove(id: "4"){ id }
parent: remove(id: "1"){ id }
}
We didn't want to go the route of having the removal of the parent take the children so we can catch potentially erroneous behavior and ask the user what they want to do (i.e. move the children to another parent, or actually remove all the children).
Ah, I see. Query batching as currently implemented in Apollo Server would work for this I think, but ordering isn't actually guaranteed (unlike putting multiple mutations in a single operation, as you've done above).
Would something like remove(id: ..., cascadeToChildren: true) or a batch removeAll(ids: ) be an alternative?
I was considering the removeAll(ids: [ID]!) route. The only downside is we lose the nice error tracing that GraphQL gives us. i.e. If ID number 3 fails, then the multiple mutations in a single operation would give us a trace to that failed mutation and the client would know to deal with just that failed mutation. With removeAll, a custom error format would be required to give us that kind of functionality.
I also think I might not quite understand how query batching works in Apollo Server. Does the batching simply let you send multiple operations in a row? If that's the case then you're right it's probably not what I'm looking for. Instead what I was describing is a sort of mutateInSequence method that takes a list of mutations and merges them into that un-named operation and runs that. It'd be really cool but also sounds nasty to implement 馃槃
Depending on the underlying service or datastore, a single mutation would have the benefit that you can run it in a transaction and have everything automatically rolled back when a removal fails. But you're right, there is no built-in way to include an error per id. Perhaps you could define a custom result object if you really need it. Something like:
removeAll(ids: $ids) {
removedItems {
id
}
}
Query batching in Apollo Server is indeed just a way to send multiple operations in one request. Currently operations are executed in sequence I believe, but it is not guaranteed and we may want to execute them in parallel.
Hi @martijnwalraven, are there any plans on adding support for Transport-level query batching?
Our app can do multiple queries at once and then it would be useful if those could be send to the server in 1 request instead of multiple request.
Hey guys,
Do we have any plans on supporting query batching? Is there a doc we can refer to about the roadmap of Apollo-iOS?
Marking this as an enhancement - I don't have a timeline for this but it does seem like a useful thing to add support for to reduce the number of round-trips necessary if possible.
@thonydam Right now we don't have a roadmap doc, but I'll be working on that at some point in the next few months once I get the open issues a bit more under control.
@designatednerd Thanks for the update and your work! Glad to see that this repo will get more love!
Any updates on this topic?
(This topic is mixed with another and followed up on https://github.com/apollographql/apollo-ios/issues/884. Not sure what the current status is though).
I'm going to look at adding both of these as we update the networking stack but I do not have an ETA.
Most helpful comment
I'm going to look at adding both of these as we update the networking stack but I do not have an ETA.