Webflux support

In this release, we added support for Webflux. Webflux support has been one of the most requested features and is now available.
The support includes the following:

• A new module graphql-dgs-reactive. The module contains a new interface DgsReactiveQueryExecutor, which is the DgsQueryExecutor you know and love, but each result is wrapped in a Mono. Internally all query processing is non-blocking. In a Webflux application, both the DgsReactiveQueryExecutor and DgsQueryExecutor will be available for injection, so that you can still use the blocking one for things like tests. Internally the Webflux integration uses DgsReactiveQueryExecutor.
• A new module graphql-dgs-spring-webflux-autoconfigure. This module contains the /graphql HTTP handler, GraphiQL support and a Websocket endpoint for subscriptions. These endpoints are implemented using Webflux, and the module does not require any webmvc modules.
• A new starter graphql-dgs-webflux-starter. You use this starter instead of the graphql-dgs-spring-boot-starter if you're using DGS in a Webflux environment.
• A new example project graphql-dgs-example-java-webflux. This project shares most of the code with the graphql-dgs-example-java, but based on a Webflux stack.

A (breaking) change to DgsRequestData.

In a recent release we added DgsRequestData to the DgsContext. We designed this to be usable both from WebMVC and Webflux, by using the WebRequest type from Spring's web module. However, this turned out to be a mistake. Webflux uses a ServerRequest type instead.

To cleanly fix this issue and not create a suboptimal dependency graph, we made a small breaking change to the API. DgsRequestData is now an interface, with two implementations: DgsWebMvcRequestData and DgsReactiveRequestData. Only if you need access to either WebRequest or ServerRequest in your data fetcher, you need to type check and cast to the correct implementation to get access to WebRequest or ServerRequest.
If you were using WebRequest from DgsRequestData, your code will no longer compile with this release without adding the extra type cast. This should be an easy fix but is the reason we decided on a major release.

A breaking release!?

As explained in the previous paragraph, we had to introduce a change to the DgsRequestData type. Because this is an API type, this requires a major release. Since this will only impact very specific use cases, it will likely not cause any changes for most users.

We also took the opportunity to remove the previously deprecated DgsContextBuilder. Remember that this interface has long been obsolete because we have the custom context concept.

Aside from these two changes, there are no other changes affecting backward compatibility. The Webflux modules are optional and don't impact existing WebMVC users.

We need your testing!

The Webflux integration is obviously a big feature, and we could be missing certain issues and corner cases. Please try it out and report any issues! PRs are always welcome as well.
To test with an RC release, add the https://netflixoss.jfrog.io/artifactory/maven-oss-candidates/ to your build configuration.

gradle.build

repositories {
    mavenCentral()
    maven {
        url = uri("https://netflixoss.jfrog.io/artifactory/maven-oss-candidates/")
    }
}

dependencies {
    implementation platform("com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:4.0.0-rc.1")
}

gradle.build.kts

repositories {
    mavenCentral()
    maven {
        url = uri("https://netflixoss.jfrog.io/artifactory/maven-oss-candidates/")
    }
}

dependencies {
    implementation(platform("com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:4.0.0-rc.1"))
}

Complete list of changes

• WebFlux support (#301) @paulbakker
• Update example to use dataloader with Try (#316) @srinivasankavitha
• Transient failure on MicrometerServletSmokeTest (#314) @berngp
• Test Example Application as part of the CI Process (#311) @berngp