Replies: 1 comment 2 replies
-
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? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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:
Such a DataFetcher wouldn't work if registered through
@DgsCodeRegistry
asGraphQLCodeRegistry.Builder
comes from graphql-java and doesn't know aboutDataFetcherResultProcessor
(which is used to implement the support forMono
).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.Beta Was this translation helpful? Give feedback.
All reactions