spring-graphql compatible code generation
See original GitHub issueNow that spring-graphql is 1.0 and reasonably stable, it would be good to provide first class support for their structures.
Currently @QueryMapping, @MutationMapping and @SubscriptionMapping can be shoe-horned in via customAnnotationsMapping with something like:
"customAnnotationsMapping": {
"^Query\\.\\w+$": ["org.springframework.graphql.data.method.annotation.QueryMapping"],
"^Mutation\\.\\w+$": ["org.springframework.graphql.data.method.annotation.MutationMapping"],
"^Subscription\\.\\w+$": ["org.springframework.graphql.data.method.annotation.SubscriptionMapping"]
}
But that falls short on parameterised resolvers, or resolvers for extensions which are generated separately which rely on spring’s @SchemaMapping(typeName = "MyGraphQLType")
(and so need to be manually added)
Likewise use of @Argument
for all input parameters can be manually added to the implementing classes, but would be convenient to have on the generated interfaces.
There are other parameter types that can be provided (see https://docs.spring.io/spring-graphql/docs/current/reference/html/#controllers). Adding these with similar configuration as exists today for DataFetchingEnvironment would also be useful and would provide reasonably complete with what spring-graphql offers.
Also note that there is a feature request in spring-graphql for code generation: https://github.com/spring-projects/spring-graphql/issues/159 which would effectively be solved with this functionality.
Issue Analytics
- State:
- Created a year ago
- Reactions:4
- Comments:13 (6 by maintainers)
Top GitHub Comments
Added support of 2 configs:
resolverArgumentAnnotations
andparametrizedResolverAnnotations
which should solve abovementioned problems:resolverArgumentAnnotations
This will add the specified annotation to every argument in every method in each Query/Mutation/Subscription resolver:
parametrizedResolverAnnotations
This will add the specified annotation to every field resolver method:
Let me know what you think.
The custom annotations mapping you provided works well for me too.
The main issue for me is not being able to annotate the arguments with @Argument.
Maybe a customResolverArgumentAnnotations option would be good? It could just take a list of annotations to be applied to all arguments. But not the DataFetchingEnvironment etc