The following circularity is problematic for users:
- Interface types require a type resolver, and type resolvers must be able to reference the object types they need to resolve.
- However, object types need to be able to reference the interfaces that they implement.
For example:
public class Schema {
public static GraphQLInterfaceType AnimalType = newInterface()
.name("Animal")
.field(newFieldDefinition().name("name").type(GraphQLString).build())
.typeResolver(new TypeResolver() {
@Override
public GraphQLObjectType getType(Object object) {
return BirdType;
}
})
.build();
public static GraphQLObjectType BirdType = newObject()
.name("Bird")
.withInterface(AnimalType)
.field(newFieldDefinition().name("name").type(GraphQLString).build())
.build();
}
In the above example, the AnimalType type resolver can forward reference BirdType because it is implemented as an anonymous class.
However, this does not work if the type resolver is implemented as a lambda:
public static GraphQLInterfaceType AnimalType = newInterface()
.name("Animal")
.field(newFieldDefinition().name("name").type(GraphQLString).build())
.typeResolver(obj -> BirdType)
.build();
In this case, BirdType must be referenced by its fully qualified name: Schema.BirdType:
.typeResolver(obj -> Schema.BirdType)
The situation is further complicated when schema types are not defined as class members. For example, there is no direct way to resolve the circularity above if the same schema is defined within a method body.
public class Schema {
public static void main(String[] args) {
GraphQLObjectType BirdType = newObject()
.name("Bird")
.withInterface(AnimalType) // AnimalType is not defined
.field(newFieldDefinition().name("name").type(GraphQLString).build())
.build();
GraphQLInterfaceType AnimalType = newInterface()
.name("Animal")
.field(newFieldDefinition().name("name").type(GraphQLString).build())
.typeResolver(new TypeResolver() {
@Override
public GraphQLObjectType getType(Object object) {
return BirdType;
}
})
.build();
}
}
There is no idiomatic way to solve this issue. Looking at the tests, types are defined as class members, leading the user to conclude that that is the only way to define a schema where interface/object relationships must be defined.
This is fine, but not good. To address this issue:
- A type resolver must be declared in the interface example in the README. The example must be written in such a way that if the user follows this example, they are lead to writing code that compiles and defines a valid schema.
- The type resolver API could be improved. For example, as @idubrov suggests, the type resolver could accept the GraphQL schema as a parameter.
The following circularity is problematic for users:
For example:
In the above example, the
AnimalTypetype resolver can forward referenceBirdTypebecause it is implemented as an anonymous class.However, this does not work if the type resolver is implemented as a lambda:
In this case,
BirdTypemust be referenced by its fully qualified name:Schema.BirdType:The situation is further complicated when schema types are not defined as class members. For example, there is no direct way to resolve the circularity above if the same schema is defined within a method body.
There is no idiomatic way to solve this issue. Looking at the tests, types are defined as class members, leading the user to conclude that that is the only way to define a schema where interface/object relationships must be defined.
This is fine, but not good. To address this issue: