Spring Controller-like annotations for GraphQL

[benvenutisw]

I want to suggest an idea and checked that ...

• ... to my best knowledge, my idea wouldn't break something for other users
• ... the documentation does not mention anything about my idea
• ... there are no open or closed issues that are related to my idea

Description

The idea is to offer a set of annotations similar to the ones available in Spring for Controllers. This is how a GraphQL controller class looks like in the end:

@GraphQLController
public class PersonController {
    ...
    @GraphQLRequestMapping("Mutation:createPerson")
    public String create(
            @GraphQLRequestParam("data") Person personData,
            @GraphQLRequestHeader("SomeHeader") String someHeader) {
        return personService.createPerson(personData, someHeader);
    }
    @GraphQLRequestMapping("Query:person")
    public List<Person> list(
            @GraphQLRequestParam("selectionSet") String selectionSet,
            @GraphQLRequestParam("filter") PersonFilter filter,
            @GraphQLRequestHeader("SomeHeader") String someHeader) {
        return personService.list(selectionSet, filter, someHeader);
    }
    ...
}

Basically, we would offer the following annotations:

• GraphQLController: identifies a class as a GraphQL controller and make it available in Spring as a component.
• GraphQLRequestMapping: maps a method to a data fetcher, defining the related Type:Field
• GraphQLRequestParam: injects received arguments in the annotated method parameter, including a string representing the selection set
• GraphQLRequestHeader: extracts a header from the GraphQL request and injects in the annotated method parameter

These annotations make the controller almost GraphQL agnostic (almost because it still needs to know that the selection set is GraphQL representation of the requested fields).

But why did we create these annotations? First of all, to avoid the boiler plate to extract/convert the arguments and headers to java objects. They also make the testing part really easier, as the tester doesn't need to mock/instantiate graphql-specific objects (besides selection set).

Use Cases

• Extract an argument value and make it available as an argument of a given method
• Extract the selection set and make it available as an argument of a given method. Useful, for instance, when delegating the execution of an operation to another service whose schema is being extended
• Extract the value of a given header from the income request
• Easily define Controller classes
• Easily test the controller-like classes with minimal mocking/creation of specific graphql objects