Make dynamically registered DataFetchers consistent with annotation-based approach

[ivanasen]

DataFetchers registered using @DgsCodeRegistry are not registered in the same way as DataFetchers coming from @DgsData. This creates unexpected behaviour when using the framework for edge cases in which we want to generate schema dynamically.

For example, in a Spring project, we can have an annotation-based DataFetcher that returns a Reactor Mono:

@DgsData(...)
public Mono<...> example() { ... }

Such a DataFetcher wouldn't work if registered through @DgsCodeRegistry as GraphQLCodeRegistry.Builder comes from graphql-java and doesn't know about DataFetcherResultProcessor (which is used to implement the support for Mono).

This idea is to implement a "wrapper" of GraphQLCodeRegistry.Builder which will be injected instead, and would process the dynamically registered DataFetchers in the same way as they are registered through declarative annotations. Based on the method signature under @DgsCodeRegistry we can still preserve backward compatibility with the old version and not break existing code.

[Emily]

Hey @ivanasen,

This seems like a pretty reasonable idea to me. I suspect we'd accept a PR that adds such functionality. The only wrinkle might be the ongoing project to change the library to be a layer on top of spring-graphql (see: #1766). @paulbakker @srinivasankavitha any thoughts here?

[srinivasankavitha]

This should be ok to address independent of the spring-graphql integration.

[ivanasen]

Thanks, I opened a PR.