How to replace the whole engine

[andimarek]

Hi,

how would I replace the whole GraphQL Java engine with a custom implementation in Spring GraphQL?

What I mean is:

I would like to implement a custom ExecutionGraphQlService and therefore use all the transport level support, but everything else is custom.

I will also not have any Schema file (therefore the GraphQlAutoConfiguration will not run) or any Controller with mappings.

How would that look like in Spring GraphQL?

If I register just a custom ExecutionGraphQlService and a custom GraphQlProperties that causes the following error:

Parameter 2 of method graphQlRouterFunction in org.springframework.boot.autoconfigure.graphql.reactive.GraphQlWebFluxAutoConfiguration required a bean of type 'org.springframework.graphql.execution.GraphQlSource' that could not be found.

But I don't want any GraphQlSource instance.

Btw: I understand that this is not a common use case and it maybe very well out of scope, but nevertheless it would be great to be able to reuse all the awesome HTTP/Transport logic in Spring GraphQL.

Thanks team!

[rstoyanchev]

Some initial thoughts below, but not knowing the exact situation, it may take a bit of back and forth.

I'm wondering if you really need to replace DefaultExecutionGraphQlService? At that level we don't care about controllers and mappings. It's just about calling the GraphQL Java engine.

graphQlRouterFunction needs GraphQlSource for the handler that prints the schema. GraphQLSource is a trivial interface that you could just implement without involving on any of the supporting infrastructure. Or you could also extend AbstractGraphQlSourceBuilder, which does not make assumptions about how GraphQLSchema is prepared.

[bclozel]

I had a look at the current state of the Spring Boot auto-configuration and in fact we should probably untangle the main auto-configuration from the transports one.

Currently GraphQlProperties binds:

• spring.graphql.schema.* for schema setup, inspection, printer and introspection
• spring.graphql.path is for the HTTP transport only
• spring.graphql.graphiql.* for GraphiQL
• and then spring.graphql.websocket.*, spring.graphql.rsocket.*, spring.graphql.sse.* for other transports

Maybe we should ensure that transport properties are still bound even if the main auto-configuration is not considered. This would solve the GraphQlProperties bean issue. In the process, we should rename spring.graphql.path to spring.graphql.http.path.

The main auto-configuration is processed (and so the properties are bound) only if one of the following is true:

• schema files are found in the GraphQlProperties configured locations
• one or more GraphQlSourceBuilderCustomizer beans are present
• a GraphQlSource bean is present

This sounds reasonable. I think the second problem comes from the fact that the HTTP transport expects both an ExecutionGraphQlService and a GraphQlSource bean. I think we should make the GraphQlSource bean optional in the HTTP transport auto-configuration.

Those changes sound quite sensible, independently of this use case being considered.

[bclozel]

I took care of the Spring Boot side of things in spring-projects/spring-boot#44495.
I don't think there is anything else to cover here, so I'm closing this issue for now.
We can reopen if we miss something here.

[andimarek]

Thanks @bclozel , but how do I use this? :-) Or is everything document in the spring boot link? thanks

[bclozel]

This change should be available in the latest Spring Boot 3.5.0-SNAPSHOTs. This is a significant change so pushing this to the current 3.4.x generation was not an option. Spring Boot 3.5.0-M3 will be released in a couple of weeks, the GA version is scheduled for May.

A couple of configuration properties are deprecated with direct replacements, see https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.5.0-M3-Release-Notes#miscellaneous. The properties migrator should help you with that.

[andimarek]

thanks a lot @bclozel