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
idof the film and the implied__typename, because in the schemaFilmis a type not an interface) - The query returns a single instance of
Film, withidmatching 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?