I’m trying to understand how or if I could persuade apollo gateway to leverage parallel execution for this query:
{
film(id: "1") {
id
name
reviews { text }
}
}
Here the film(id: "1")
query returns a Film by its ID from the films subgraph (which contributes the id
and name
fields), while the reviews subgraph contributes the reviews
field (given a particular Film id)…
The reported query plan is:
QueryPlan {
Sequence {
Fetch(service: "films") {
{ film(id: 1) { __typename id name } }
},
Flatten(path: "film") {
Fetch(service: "reviews") {
{ ... on Film { __typename id } } =>
{ ... on Film { reviews { text } } }
}
}
}
}
On the one hand, the fact that these 2 Fetches are serial is obvious; the gateway doesn’t know that the result of the first Fetch is essentially already “identified” by dint of the fact that:
- The query inputs already contain all the information needed for the second Fetch (i.e. the
id
of the film and the implied__typename
, because in the schemaFilm
is a type not an interface) - The query returns a single instance of
Film
, withid
matching that requested
But on the other hand, it feels like such an obvious opportunity for parellelism that occurs many times in my experience (i.e. find an instance by its id
, then add in a few fields to that instance from other subgraphs).
Am I barking up the wrong tree here? Is this a valid argument, and are there any existing ways or future plans to address this?