Dependency graph design

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.

[andimarek]

After giving it some more thought and actually implementing it/spiking it, I come up with a design where each node represents always a field of an object type. Fragments/type condition/field on interfaces are all resolved to fields on object types. At execution time only object types matter and which interfaces/union is implemented by which object is statically known by the schema definition.

I created also a small interactive page to play around/visualize this: https://www.graphql-analyzer.com/

A PR which adds this dependency graph to GraphQL Java will follow.

[andimarek]

closing this now … thanks a lot @gkesler @exbe for the valuable discussion!