Provide a synchronous GraphQL client without spring-webflux

[juergenzimmermann]

It would be nice to have a synchroneous GraphQL client like org.springframework.web.client.RestClient (provided by spring-web-VERSION.jar).
The current org.springframework.graphql.client.HttpGraphQlClient is based on org.springframework.web.reactive.function.client.WebClient and, therefore, requires spring-webflux-VERSION.jar.

[bclozel]

We could consider a GraphQlClient that does not depend on WebClient, but we would still depend on reactor-core because of the Mono and Flux signature types. This would not make the client synchronous as outlined in the issue title. Would this still work for you?

[juergenzimmermann]

@bclozel sounds good. This way at least org.springframework:spring-webflux resp. org.springframework.boot:spring-boot-starter-webflux will become obsolete for GraphQL apps.

[rstoyanchev]

@juergenzimmermann we'll consider a synchronous GraphQlClient along the lines of having RestClient and WebClient side by side, but that only adds another choice. It does not make spring-webflux obsolete for GraphQL applications. GraphQL with it's scatter-gather style handling benefits from concurrent execution, and the same can also be quite useful on the client side too if processing multiple requests.

[juergenzimmermann]

@rstoyanchev Thank you for the clarification. I highly appreciate having a synchronous GraphQlClient, also for testing purposes.

[rstoyanchev]

For testing we have GraphQlTester which has a synchronous API unless you are testing subscriptions but in that case you need Reactive Streams anyway with GraphQL Java.

[rstoyanchev]

This is now available in 1.3.0-SNAPSHOT from https://repo.spring.io/snapshot.

Please, review the updated Client section, including the HTTP Sync extension backed by RestClient, and the Requests section with code snippets.

As a general comment, you can now choose between blocking (e.g. RestClient) and non-blocking (e.g. WebClient) execution chains for the underlying transport and interceptors. At the top-level, the GraphQlClient remains a shared, common workflow that offers both synchronous and non-blocking style of performing requests that you can use with any transport.

If you are able to give this a try and provide feedback, that would be much appreciated!

[juergenzimmermann]

@rstoyanchev Thank you very much, also for the updated docs!. The snapshot works perfectly.