What’s Changed

• Have the CI Gradle Build provide additional info (#386) @berngp
• Addressing typos in metadata file (#385) @berngp
• Metric tags gql.operation, gql.operation.name, gql.query.complexity, gql.query.sig.hash (#382) @berngp
• Add Httpheader argument in executeAndExtractJsonPathAsObject (#372) @samhon
• Improve error handling and null data semantics for entity fetchers. (#383) @srinivasankavitha
• Fix documentation for inclusivity. (#378) @srinivasankavitha

What’s Changed

• Exclude synthetic fields added by jacoco during serialization of GraphQLQueryRequest (#364) @srinivasankavitha
• add httpHeaders for executeAndGetDocumentContext and fix typo (#360) @sbilello
• Bump mockk from 1.10.3-jdk8 to 1.11.0 (#357) @dependabot

What’s Changed

• Integrating Dependabot to Github Actions to flag version updates. (#356) @berngp
• Upgrade Nebula OSS Plugins (#352) @berngp

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.

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.

An example application is available as well: https://github.com/netflix/dgs-examples-webflux

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.

Scalars in DGS Client

Custom scalars can be used in input types in GraphQL. Let's take the example of a DateRange scalar that represents a "from" and "to" date.
In Java, we want to represent this as a DateRange class that takes a LocalDate for the from and to fields.
When generating a query API we want to be use the API as follows:

new GraphQLQueryRequest(
                ReviewsGraphQLQuery.newRequest().dateRange(new DateRange(LocalDate.of(2020, 1, 1), LocalDate.now())).build(),
                new ReviewsProjectionRoot().submittedDate().starScore(), scalars);

When sending the query, we somehow have to serialize this DateRange though.
There are many ways to represent a date, so how do we make sure that we use the same representation as the server expects?

In this release we added an optional scalars argument to the GraphQLQueryRequest constructor.
This is a Map<Class<?>, Coercing<?,?> that maps the Java class representing the input to an actual Scalar implementation.
This way you can re-use exactly the same serialization code that you already have for your scalar implementation or one of the existing ones from for example the graphql-dgs-extended-scalars module.

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
• Scalar in client (#333) @paulbakker
• Publish the Surefire Reports as part of the Github Actions. (#337) @berngp
• Increment the output on executing the example's tests. (#336) @berngp
• Added TYPE_HIERARCHY strategy to DsgData annotation scanning (#320) @zaenk
• Use AopUtils when looking for @DgsTypeResolver (#327) @paulbakker
• Bug fix to handle query variables in websocket subscriptions. (#332) @srinivasankavitha
• Fix example app config. (#325) @srinivasankavitha
• Escape quotes and backslashes on request serialization (#349) @richardcresswell
• Revert "Update Gradle Wrapper from 6.8.3 to 7.0.2" (#346) @berngp
• Update Gradle Wrapper from 6.8.3 to 7.0.2 (#343) @github-actions
• Serialize Map types in GraphQLQuery (#340) @richardcresswell
• Increase verbosity due a transient test failure. (#341) @berngp
• Disabling CI Test Reports for now (#342) @berngp

What’s Changed

• Scalar in client (#333) @paulbakker
• Publish the Surefire Reports as part of the Github Actions. (#337) @berngp
• Increment the output on executing the example's tests. (#336) @berngp
• Added TYPE_HIERARCHY strategy to DsgData annotation scanning (#320) @zaenk
• Use AopUtils when looking for @DgsTypeResolver (#327) @paulbakker
• Bug fix to handle query variables in websocket subscriptions. (#332) @srinivasankavitha
• Fix example app config. (#325) @srinivasankavitha

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

What’s Changed

We are reverting the "Rename packages from autoconfig -> autoconfigure" (#309) to avoid introducing breaking changes on a minor release.

What's Changed

• DgsQueryExecutor.executeAndExtractJsonPath overloading for httpHeaders #302 @sbilello
• Implement calculation of query complexity metric. #300 @srinivasankavitha
• Adding the graphql-dgs-spring-boot-micrometer to the example #297 @berngp
• Rename packages from autoconfig -> autoconfigure #279 @bono007
• Removing dependencies to rxjava in favor of reactor. #295 @berngp
• Switch to -Xjvm-default=enable compiler flag #287 @kilink
• Added comments about controller classes being "open" #278 @paulbakker
• Add open keyword to class definition of @RestController classes #275 @lucatk
• Added docs to DgsQueryExecutor #276 @paulbakker
• Updated GraphQL Java Extended Scalars version in platform BOM #273 @marceloverdijk

Candidate release to test query complexity metric.

Creating a candidate release to test metrics.

What’s Changed

Highlights

Support for Optional input arguments

Input arguments are often defined as optional in schemas.
Your datafetcher code needs to null-check arguments to check if they were provided.
Instead of null-checks you can wrap an input argument in an Optional.

public List<Show> shows(@InputArgument(collectionType = ShowFilter.class) Optional<ShowFilter> filter)

You do need to provide the type in the collectionType argument when using complex types, similar to using lists.
If the argument is not provided, the value will be Optional.empty().
It's a matter of preference to use Optional or not.

Auto-Configuration that registers graphql-java-extended-scalars' Scalars

If you use scalars from the graphql-java-extended-scalars library, such as Long, we now have a convenient way to register the scalars to your DGS. Simply add the graphql-dgs-extended-scalars module to your Gradle/Maven build and the scalars will be automatically registered.
More information about further configuration knobs can be found in the docs.

Configure the location of the GraphQL Schema Files

You can now configure the location of your GraphQL schema files via the dgs.graphql.schema-locations property.
By default it will attempt to load them from the schema directory via the Classpath, i.e. using classpath*:schema/**/*.graphql*.
Let's go through an example, let's say you want to change the directory from being schema to graphql-schemas,
you would define your configuration as follows:

dgs:
    graphql:
        schema-locations:
            - classpath*:graphql-schemas/**/*.graphql*

Now, if you want to add additional locations to look for the GraphQL Schema files you an add them to the list.
For example, let's say we want to also look into your graphql-experimental-schemas:

dgs:
    graphql:
        schema-locations:
            - classpath*:graphql-schemas/**/*.graphql*
            - classpath*:graphql-experimental-schemas/**/*.graphql*

Complete list of merged pull requests

• Bugfix: Allow JSON Documents with DateTime scalars to be deserialized to Objects (#271) @richardcresswell
• Use Micrometer APIs compatible with both Micrometer 1.5 and 1.6 (#268) @berngp
• Support Optional for @InputArgument (#267) @paulbakker
• Fix for #250, defaultValue and required arguments (#264) @paulbakker
• Update versions for Spring, Spring Security, Spring Cloud, Kotlin, and Jackson (#263) @berngp
• Upgrading to Spring Boot to 2.3.9.RELEASE (#261) @berngp
• Exceptions thrown by DgsEntityFetcher should be handled (#253) @srinivasankavitha
• Revert "Update Gradle Wrapper from 6.8.3 to 7.0" (#254) @berngp
• Update Gradle Wrapper from 6.8.3 to 7.0 (#252) @github-actions
• Use DgsQueryExecutor instead of MockMVC (#244) @berngp
• Auto-Configuration that registers graphql-java-extended-scalars' Scalars (#242) @berngp
• Define a recommendation for graphql-java-extended-scalars (#232) @berngp
• Fix for #200. Annotations should respect @AliasFor (#227) @paulbakker
• The Platform is exposed as API to address composite builds (#225) @berngp
• Introduced dgs.graphql.schema-locations configuration property (#210) @marceloverdijk
• Allow specifying the operation name and query names (#195) @lucastorri

What’s Changed

Highlights

BOM

We now have a BOM/Gradle platform defined for the framework. A BOM helps to align versions of dependencies.
We have two different BOM definitions, graphql-dgs-platform-dependencies and graphql-dgs-platform. The latter only defines version alignment for the DGS modules. graphql-dgs-platform-dependencies also defines versions for the dependencies of the DGS framework, such as Spring, Jackson and Kotlin.

In a DGS project, you can use the BOM as follows.

dependencies {
        //DGS BOM/platform dependency. This is the only place you set version of DGS
	implementation(platform("com.netflix.graphql.dgs:graphql-dgs-platform-dependencies:3.10.2"))
	
        //DGS dependencies. We don't have to specify a version here!
        implementation("com.netflix.graphql.dgs:graphql-dgs-spring-boot-starter")
	implementation("com.netflix.graphql.dgs:graphql-dgs-subscriptions-websockets-autoconfigure")

       //Additional Jackson dependency. We don't need to specify a version, because Jackson is part of the BOM/platform definition.
       implementation("com.fasterxml.jackson.datatype:jackson-datatype-joda")
        
       //Other dependencies
}

Notice that the version is only specified on the platform dependency, and not on the graphql-dgs-spring-boot-starter and graphql-dgs-subscriptions-websockets-autoconfigure. The BOM will make sure that all dependencies are the same version. Additionally, we can use the DGS chosen version of some dependencies as well, such as Jackson.

Note that the versions in the platform are recommendations. The versions can be overridden by the user, or by other platforms you might be using (such as the Spring dependency-management plugin).

Shorthand annotations

We've added shorthand annotations for defining @DgsData fields on Query/Mutation/Subscription.

The following datafetcher definitions are all equivalent.

@DgsData(parentType = "Query", field = "shows")
public List<Show> shows() { .... }

// The "field" argument is omitted. It uses the method name as the field name.
@DgsData(parentType = "Query")
public List<Show> shows() { .... }

// The parentType is "Query", the field name is derived from the method name.
@DgsQuery
public List<Show> shows() { .... }

// The parentType is "Query", the field name is explicitly specified.
@DgsQuery(field = "shows")
public List<Show> shows() { .... }

The same works for @DgsMutation and @DgsSubscription.

Support for @RequestParam

Thanks to @iuliiasobolevska you can now use the @RequestParam annotation as a datafetcher argument.
This is very similar to the @RequestHeader we previously added, but gets a request parameter.

@DgsQuery
public List<Show> shows(@RequestParam String someParameter) { ... }

Complete list of merged pull requests

• Added @DgsMutation, @DgsQuery and @DgsSubscription (#190) @paulbakker
• Add validation to DgsWebMvcConfigurationProperties (manual approach) (#176) @bono007
• Fix for #130:Unsafe TypedGraphQLError constants (INTERNAL, NOT_FOUND...) (#184) @paulbakker
• Account for custom servlet context paths in GraphiQL callback (#175) @bono007
• DgsContextBuilder should not have state (#183) @paulbakker
• Introduce a Platform BOM (#203) @berngp
• Use AopUtils to find target classes for proxies (#196) @kilink
• Add support for Spring's @RequestParam annotation (#199) @iuliiasobolevska
• Fixing Sonatype deployment by using mathematical notation when defining versions (#224) in the BOM. @berngp

Enjoy the release, and we already have a number of features lined up for another release that will follow soon!

What’s Changed

• Added @DgsMutation, @DgsQuery and @DgsSubscription (#190) @paulbakker
• Add validation to DgsWebMvcConfigurationProperties (manual approach) (#176) @bono007
• Fix for #130:Unsafe TypedGraphQLError constants (INTERNAL, NOT_FOUND...) (#184) @paulbakker
• Update to Jackson 2.12.2 (#174) @kilink
• Account for custom servlet context paths in GraphiQL callback (#175) @bono007
• DgsContextBuilder should not have state (#183) @paulbakker
• Introduce a Platform BOM (#203) @berngp
• Use AopUtils to find target classes for proxies (#196) @kilink
• Add support for Spring's @RequestParam annotation (#199) @iuliiasobolevska

What’s Changed

• Reverting to use implementation as scope for graphql-dgs-platform. (#219) @berngp

What’s Changed

• Avoid graphql-dgs-platform from being exported in submodules (#218) @berngp

What’s Changed

• Fixing BOM Nebula Metadata (#214) @berngp

What’s Changed

• Introduce a Platform BOM (#203) @berngp
• Use AopUtils to find target classes for proxies (#196) @kilink
• add support for Spring's @RequestParam annotation (#199) @iuliiasobolevska

What’s Changed

• Added @DgsMutation, @DgsQuery and @DgsSubscription (#190) @paulbakker
• Add validation to DgsWebMvcConfigurationProperties (manual approach) (#176) @bono007
• Fix for #130 (#184) @paulbakker
• Update to Jackson 2.12.2 (#174) @kilink
• Account for custom servlet context paths in GraphiQL callback (#175) @bono007
• DgsContextBuilder should not have state (#183) @paulbakker