Thank you for creating this library, I think it's great.

This is certainly a minor issue, but I'm finding that almost all of my resolver methods end up taking the DataFetchingEnvironment as an argument and calling #getContext() on it. This is to allow my business logic layer to inspect the authenticated user to make authorization decisions.

For example:

public class MutationResolver implements GraphQLMutationResolver {
    private final MyService myService;

    @Inject
    public MutationResolver(MyService myService) {
        this.myService = myService;
    }

    public Thing createThing(ThingInput thing, DataFetchingEnvironment environment) {
        return myService.createThing(environment.getContext(), thing);
    }
}

In this example MyService#createThing would take a Viewer object as it's first argument.

This pattern certainly works, but the boiler plate of calling DataFetchingEnvironment#getContext() becomes a little verbose as the number of resolver methods grows.

One way to solve this would be to allow users to configure graphql-java-tools to pass a custom context class (Viewer in the example above) as an argument to resolver methods, much in the same way as DataFetchingEnvironment is done today.

It occurs to me that I may be following the wrong pattern here but I can't think of another way to get my Viewer object into my business logic layer.

What do you think?