Refactor GraphQlSource builder to separate programmatic vs SDL way of create GraphQLSchema

[ruben-garciapariente]

We would like to be able to define the schema programmatically instead of through an SDL file.
In our first attempt we have used a GraphQlSourceBuilderCustomizer and used the schemaFactory method, but we noticed that the DefaultTypeResolver is not registered correctly and it is necessary to have an SDL file even if it is empty.

Could you consider adding a method to the DefaultGraphQlSourceBuilder that would allow to directly insert a GraphQLSchema?

Many thanks & regards,
Rubén

[rstoyanchev]

Generally, SDL is what we aim to support support and that's what GraphQlSource.Builder is built for. I'm not sure we should aim to support the programmatic approach in the same builder. I would be concerned about the full implications of what that entails, what Builder options apply to which, but also what else might not work in combination.

If we wanted to support programmatic, it would maybe be a different builder, or perhaps the two builders could share a common base builder, but again I have not looked in detail and it is not planned currently.

For now, consider bypassing the builder and creating a GraphQlSource through your code. If there are issues with that approach we could consider small changes to make it possible at least.

[ruben-garciapariente]

Thank you very much for your suggestion. I tried to create my own GraphQlSource. I did a quick test and got it working, but I had to make a number of ugly changes in spring-graphql:

1. To inject the DataFecher in the SDL you are using RuntimeWiring.Builder, but to be able to do this without SDL you need GraphQLCodeRegistry.Builder (at least I didn't know how to do it otherwise).
   To solve this I have modified the AnnotatedControllerConfigurer class and created a new configure(GraphQLCodeRegistry.Builder builder) method with the code practically identical to configure(RuntimeWiring.Builder builder). In addition to creating an interface equivalent to RuntimeWiringConfigurer but for GraphQLCodeRegistry.Builder
   If we want to use QueryDSL we would have the same problem. To solve it I created a class equivalent to AutoRegistrationRuntimeWiringConfigurer but for GraphQLCodeRegistry and I created a new static method in QuerydslDataFetcher equivalent to autoRegistrationConfigurer.

2. To avoid repeating a lot of code I made public:

• ContextDataFetcherDecorator and its TYPE_VISITOR attribute.
• ExceptionResolversExceptionHandler

In short, I haven't seen a simple way to make it work with small changes :_______(

[rstoyanchev]

Thanks for sharing the outcome. For the RuntimeWiringConfigurer, I'm wondering if it would work to create your own RuntimeWiring.newRuntimeWiring() then use AnnotatedControllerConfigurer to accumulate the registrations, and in the end build and get the CodeRegistry from RuntimeWiring?

Overall I'm wondering if we could open things up a bit with the GraphQlSource.Builder implementation and perhaps have a base class that's agnostic to SDL vs programmatic schema creation.

[ruben-garciapariente]

Thank you very much for your advice. I have tried using the CodeRegistry obtained from RuntimeWiring, but it doesn't seem like a viable alternative.

When the dataFetcher are registered in RuntimeWiring.Builder, they are not registered in GraphQLCodeRegistry. I check this because when get the CodeRegistry from runtimeWiring.getCodeRegistry(), the dataFetcherMap attribute is empty.
On the other hand, if I register the dataFecher directly in GraphQLCodeRegistry.Builder, the dataFetcherMap object does contain the registered dataFecher.

Instead, maybe it is possible to do it the other way around (correctly generate a RuntimeWiring from a GraphQLCodeRegistry).

If this is really as I have seen, could it make sense to change the public void configure(RuntimeWiring.Builder builder builder) method to configure(GraphQLCodeRegistry.Builder builder builder)?

[rstoyanchev]

You're right that RuntimeWiring builder doesn't populate the CodeRegistry, but it gives you access to the data fetcher registrations, and it would be trivial to add those to the CodeRegistry. That's what SchemaGeneratorHelper does later on from the RuntimeWiring.

I don't think there is any benefit to change AnnotatedControllerConfigurer to populate the CodeRegistry directly.