Auto-Binding Support for Arguments in Queries and Mutations

[williamwjs]

Hi team,

I have been using the graphql-java-kickstart/graphql-spring-boot project for my project, which is now deprecated in favor of this spring project.

In the past, I did not have to annotate the arguments for the query or mutation. However, with this spring-graphql project, it seems I will need to annotate them.

I am wondering if it would be beneficial to support auto-binding of arguments based on field name, type, etc.? This would simplify the transition and reduce the amount of boilerplate code required.

Thank you!

[rstoyanchev]

Thanks for the feedback.

We allow the "source" (i.e. parent) to be injected without annotations, so if no other resolver recgonizes the method parameter as supported, we try to resolve it as the source.

We could expand this to fall back on the "source" as long as it matches the method parameter type, or otherwise resolve it as an argument, but in doing so that we wouldn't have an opportunity to raise an error for a method parameter that is not supported or expected, and instead a null would be passed in.

I think @Argument serves as a good indication of intent. However, if you have an API with lots of arguments per query, keep in mind that you can also bind all of them to a single object that contains them via @Arguments. The plural version of the annotation binds from the whole arguments map, see the reference docs.

If you really want the expanded fallback behavior, it's easy to create an argument resolver that does something along these lines:

public class FallbackArgumentResolver implements HandlerMethodArgumentResolver {

	private final ArgumentMethodArgumentResolver argumentResolver;

	public FallbackArgumentResolver(ArgumentMethodArgumentResolver argumentResolver) {
		this.argumentResolver = argumentResolver;
	}

	@Override
	public boolean supportsParameter(MethodParameter parameter) {
		return true;
	}

	@Override
	public Object resolveArgument(MethodParameter parameter, DataFetchingEnvironment env) throws Exception {
		return parameter.getParameterType().isInstance(env.getSource()) ?
				env.getSource() : this.argumentResolver.resolveArgument(parameter, env);
	}
}

If you register that as a custom resolver, it will be invoked after all other built-in resolvers, but before the one for the "source" so effectively taking over the fallback behavior and resolving arguments without an annotation.

[williamwjs]

@rstoyanchev Thank you for the suggestion!
It is harder to test this now without spring-projects/spring-boot#40393, as I don't see an easy way to inject this custom Argument Resolver

[bclozel]

@williamwjs in the meantime, you can use the following:

@Configuration(proxyBeanMethods = false)
public class GraphQlConfiguration {
	
	@Bean
	BeanPostProcessor annotatedControllerPostProcessor() {
		return new BeanPostProcessor() {
			@Override
			public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
				if (bean instanceof AnnotatedControllerConfigurer configurer) {
					configurer.addCustomArgumentResolver(new CustomArgumentResolver());	
				}
				return bean;
			}
		};
	}

}

[williamwjs]

This works! Thank you!