Is your feature request related to a problem? Please describe.
In the GraphQL specification, some fields may have arguments:
https://graphql.org/learn/queries/#arguments
This schema for instance:
type Query {
users: [Person]!
}
type Person {
name: String!
height(unit: Unit): Int!
}
enum Unit {
METERS, FEET
}
Currently, graphql-java-codegen generates a Person class with both name and height fields. However, the height field is parameterized and should be defined in a separate resolver (with the parameters as method arguments).
Describe the solution you'd like
A solution that would match the https://github.com/graphql-java-kickstart/graphql-java-tools approach would be to avoid generating the height field as a field/getter/setter on the Person type, but instead generate a PersonResolver interface with a method to resolve that field, as defined by the GraphQL Java Tools project.
The method should look like:
import graphql.schema.DataFetchingEnvironment;
interface PersonResolver {
public Integer height(Person person, Unit unit, DataFetchingEnvironment env);
}
Describe alternatives you've considered
Alternatively, or in the meantime, an option to exclude parameterized fields from the generated classes would be a start.
Is your feature request related to a problem? Please describe.
In the GraphQL specification, some fields may have arguments:
https://graphql.org/learn/queries/#arguments
This schema for instance:
Currently,
graphql-java-codegengenerates aPersonclass with bothnameandheightfields. However, the height field is parameterized and should be defined in a separate resolver (with the parameters as method arguments).Describe the solution you'd like
A solution that would match the https://github.com/graphql-java-kickstart/graphql-java-tools approach would be to avoid generating the
heightfield as a field/getter/setter on thePersontype, but instead generate aPersonResolverinterface with a method to resolve that field, as defined by the GraphQL Java Tools project.The method should look like:
Describe alternatives you've considered
Alternatively, or in the meantime, an option to exclude parameterized fields from the generated classes would be a start.