I want to capture here some thoughts about the Dependency graph (see #1409).
One of the main challenges is the dynamic aspects of a query (type conditions).
For exampel for this schema:
type Query{
node: Node
}
interface Animal {
name: String
friends: [Friend]
}
union Pet = Dog | Cat
type Friend {
name: String
isBirdOwner: Bool
isCatOwner: Bool
pets: [Pet]
}
type Bird implements Animal {
name: String
friends: [Friend]
}
type Cat implements Animal{
name: String
friends: [Friend]
breed: CatBreed
}
type Dog implements Animal{
name: String
breed: DogBreed
friends: [Friend]
}
scalar DogBreed
scalar CatBreed
one can imagine this query:
{
node
... on Cat {
friends {
isCatOwner
name
pets {
name
... on Cat {
breed
}
}
}
}
... on Bird {
name
friends {
isBirdOwner
name
pets {
name
... on Dog {
breed
}
}
}
}
... on Dog {
name
}
}
The question is now how the dependency graph should capture these dynamic type conditions.
One possible way could be this:

But the value of this kind of dependency graph maybe limited because it doesn't uphold to one fundamental expectation that every field is only present once.
The /node/friends/pets/name field is duplicated because it will only be executed if we have a Bird or a Cat, but not for a Dog.
Same is true for /node/friends/pets and /node/friends/name.
The alternative could maybe look like this:

It doesn't duplicate any fields anymore but now there are complex conditions associated with some nodes. For example /node/friends/pets/breed will only be evaluated if the original node is a Cat and the pet is a Dog.
I want to capture here some thoughts about the Dependency graph (see #1409).
One of the main challenges is the dynamic aspects of a query (type conditions).
For exampel for this schema:
one can imagine this query:
{ node ... on Cat { friends { isCatOwner name pets { name ... on Cat { breed } } } } ... on Bird { name friends { isBirdOwner name pets { name ... on Dog { breed } } } } ... on Dog { name } }The question is now how the dependency graph should capture these dynamic type conditions.

One possible way could be this:
But the value of this kind of dependency graph maybe limited because it doesn't uphold to one fundamental expectation that every field is only present once.
The
/node/friends/pets/namefield is duplicated because it will only be executed if we have aBirdor aCat, but not for aDog.Same is true for
/node/friends/petsand/node/friends/name.The alternative could maybe look like this:

It doesn't duplicate any fields anymore but now there are complex conditions associated with some nodes. For example
/node/friends/pets/breedwill only be evaluated if the original node is aCatand the pet is aDog.