Annotation based approach for GraphQLContext and local context values as arguments to SchemaMapping and BatchMapping methods

[jhinch-at-atlassian-com]

Currently, the local context and the values in the GraphQLContext can only be retrieved in a data fetcher by requesting the DataFetchingEnvironment and invoking various methods on it. It would be great if annotations could be provided to allow these to be resolved as arguments to the method. This is similar to how Spring MVC currently allows quality of life annotations such as RequestHeader or CookieValue.

[rstoyanchev]

Note that we currently do support GraphQLContext as an argument, so that saves one step of having to get it from the DataFetchingEnvironment. That said we could also support an @ContextValue argument.

How would you expect that to work? Perform a lookup by key first, sourcing the key either from the annotation or from the method parameter name if available. If that doesn't find anything, we could try to use the method parameter type to find a matching value but this could get tricky or cause unexpected results with more common types. Also, since the localContext is an Object, we can only perform a lookup if it is an instance of GraphQLContext.

[Thinkenterprise]

I am of the same opinion as @jhinch-at-atlassian-com . It would be very helpful if one could easily access attributes in context via an annotation like @ContextValue("ATTRIBUTE").

I tried to access the context that I previously filled using a Spring Bean of the LocalThreadAccessor type. The debugger shows that the attribute is deeply nested in a map.

@Component
public class StaticContextInformation implements ThreadLocalAccessor{

    @Override
    public void extractValues(Map<String, Object> container) {
        container.put("MY_STATIC_VALUE_KEY", "MY_STATIC_VALUE");
        
    }
}

A simple access like here is not possible. The result was empty!!

 @QueryMapping
    public List<Route> routes(DataFetchingEnvironment dataFetchingEnvironment, GraphQLContext context) {
       
        System.out.println(context.getOrEmpty("MY_STATIC_VALUE_KEY").toString());
        System.out.println(dataFetchingEnvironment.getGraphQlContext().getOrEmpty("MY_STATIC_VALUE_KEY").toString());
        
        return routeRepository.findAll();
    }

That would be a better solution

 @QueryMapping
    public List<Route> routes(@ContextValue("MY_STATIC_VALUE_KEY") String myStaticValueKey) {
       
        System.out.println(myStaticValueKey);    
        return routeRepository.findAll();
    }

@rstoyanchev Yes, runtime errors can occur if the key is not included or a cast is not possible. But I think that's ok, and it can happen in other places too.

Or do I think too complicated and there is a much simpler solution??

[rstoyanchev]

@Thinkenterprise thanks for the question.

I think what @jhinch-at-atlassian-com proposed is to simply expose values from GraphQLContext in ExecutionInput in a more convenient manner. The context propagation feature of Spring GraphQL, on the other hand, is meant to work more transparently and you aren't expected to access that via GraphQLContext, which is just a way of getting it through to the data layer.

For example, the ThreadLocalAccessor for Spring Security enables use of SpringSecurityContextHolder from a @SchemaMapping method even though it may be on a different thread. We could probably improve the documentation in this section to make that more clear.

Having said that, I can see that an @ContextValue could work by checking top-level key-value pairs first, then fall back on checking among the saved ThreadLocal values.

[Thinkenterprise]

Thanks for the answer @rstoyanchev. I think I had a wrong idea about GraphQLContext. I thought I could create my own GraphQLContext instance, fill it with my application data and pass it on to all controllers. Obviously, that's not the point of GraphQLContext, right? Another aspect are the ThreadLocalAccessor implementations that enable access to central objects such as SecurityContext via SecurityContextHolder when threads are changed. But what is the GraphQLContext for? In the documentation, GraphQLContext is only described with one line that describes that the GraphQLContext can be accessed via controller @SchemaMapping method argument. But what is the point? And what use cases are there to do this? I am not yet fully aware of this. I think it would be useful to improve the documentation at this point. Thanks!!

[rstoyanchev]

GraphQLContext is the main mechanism in GraphQL Java for passing values to data fetchers. It is essentially a Map that is passed to all data fetchers, so a very simple mechanism that is comparable to request attributes in the Servlet API. I'm not sure if that helps to answer your question.

[Thinkenterprise]

Thanks you for explanation!! But I know the meaning of GraphQLContext. However, it is not clear to me at which point in Spring GraphQL I can create the context and pass it to the GraphEngine. For example, I would like to create a new context for each web request and fill it with certain information. In Spring Boot GraphQL from Kickstarter I have the possability to create my own GraphQLContextBuilder and create a Spring Bean over the @Configuration which will be autowired from the Kickstarter Framwork during the autoconfiguration process.

[rstoyanchev]

As of GraphQL Java 17, the ExecutionInput provides the graphQLContext() method which returns a GraphQLContext that is for shared use. The previously used getContext() which returned Object is now deprecated. The new method returns a pre-created, shared instance that your application can use and so can GraphQL, or any other framework.

In short, you no longer have to create your own GraphQLContext. Just use the one that's there.