dgs-framework

What’s Changed

• Call the ListableBeanFactory only once when fetching the MeterRegistry (#551) @berngp

What’s Changed

• Address incorrect operation tag value (#519) @berngp
• Avoid instantiating Jackson mappers per request (#501) @kilink
• Avoid chaining collection operations (#500) @kilink
• Replace ci.yml with ci-compatibility.yml (#511) @berngp
• Assert Date, Time, and DateTime Scalar serde. (#506) @berngp
• Fix assertSubscription helper method (#499) @kilink

What’s Changed

• Address incorrect operation tag value (#519) @berngp
• Avoid instantiating Jackson mappers per request (#501) @kilink
• Avoid chaining collection operations (#500) @kilink
• Replace ci.yml with ci-compatibility.yml (#511) @berngp
• Assert Date, Time, and DateTime Scalar serde. (#506) @berngp
• Fix assertSubscription helper method (#499) @kilink

What’s Changed

⚠️ Client Codegen migration to graphql-dgs-codegen-client-core (#439) @berngp

As part of an effort to migrate the DGS Client Components that should belong to the DGS Codegen project, we are removing from the graphql-dgs-client module all components in the com.netflix.graphql.dgs.client.codegen package. If you depend on them you will have to use the DGS Codegen plugin, such plugin will add a new module automatically with the artifacts. This change will allow us to evolve the both projects independently. In other words, we will not need to release a new version of the DGS Framework if we need changes to the DGS Codegen components.

Implemented @connection directive for generating SDL types for cursor-based pagination. (#487) @srinivasankavitha

As a new feature we are releasing the new graphql-dgs-pagination module. It adds support for generating schema types for cursor-based pagination based on the relay spec.

The benefit is to avoid having the user define related Connection and Edge types in the schema for every type that needs to be paginated. The following example below shows the schema the user needs to define:

type Query {
      something: MovieConnection
}
            
type Movie @connection {
    movieID: ID
    title: String
}

Note the @connection directive against the type Movie. This will generate a MovieConnection and MovieEdge as follows:

type MovieConnection {
    edges: [MovieEdge]
    pageInfo: PageInfo
}

type MovieEdge {
    node: Movie
    cursor: String
}

type PageInfo {
    hasPreviousPage: Boolean!
    hasNextPage: Boolean!
    startCursor: String
    endCursor: String
}

PageInfo is generated only once, if necessary.

Add basic support for coroutines in datafetchers (#472) @paulbakker

You can now use Kotlin Coroutines to define datafetchers. For example, let's say we have a field called range that will compute the sum between two numbers. You could define your datafetcher as follows:

@DgsQuery
suspend fun range(@InputArgument from: Int, to: Int): Int = coroutineScope {
   var sum = 0
   withContext(executor.asCoroutineDispatcher()) {
           repeat(from.rangeTo(to).count()) {
                 sum++
                 // Forcing a blocking call to demonstrate running with a thread pool
                 Thread.sleep(50)
            }
     
         sum
   }
}

Using a coroutine is very similar to returning CompletableFuture. In fact, coroutines are internally resolved as CompletableFuture.
A coroutine (similar to returning CompletableFuture) marks a datafetcher as potentially async.
However, coroutine datafetchers are dispatched using the unconfined dispatcher, which in practice means they won't automatically get any parallel behavior. This means, that multiple datafetchers defined as coroutines will still not run in parallel.

To get parallel execution, the developer is in charge of setting up the correct context. A great way to do this is using an Executor.
Also remember that any thread-bound context, such as request data stored on thread-local, will not be available when executing on a different thread. An executor has to be set up explicitly for this.
Again, this is exactly the same when using CompletableFuture for parallel datafetcheres.

Complete list of changes

• Identify implicit GQL Operation Name for the gql.operation.name tag. (#491) @berngp
• Graphiql to autoupdate url parameters (#476) @subbarao
• Added subscription test example (#488) @paulbakker
• Bump mockk from 1.11.0 to 1.12.0 (#464) @dependabot
• Reuse ObjectMapper in DgsWebSocketHandler (#468) @stdevi
• Errors should be included in a subscription response (#485) @paulbakker

What’s Changed

• Support content type that includes an encoding (#478) @paulbakker
• registry of datafetchers accessible through the schema provider (#473) @paulbakker

What’s Changed

• Use the exception handlers to process exceptions for _entities query. (#469) @srinivasankavitha
• Bump spectator-api from 0.131.+ to 0.132.0 (#463) @dependabot
• Fix handling of null variables for subscriptions and properly cleanup websocket subscriptions. (#457) @srinivasankavitha

What’s Changed

• Enable Projection Types to define the Schema Type explicitly (#451) @berngp

What’s Changed

• Remove Java Package name from Projection serialization (#444) @berngp
• DataFetchResultProcessor: add DFE as an argument (#427) @AlexRiedler
• Mark RestController attributes as open val to allow CGLIB proxying (#428) @lucatk
• Added serialization for fragments (#418) @paulbakker
• Added a DgsDataLoaderRegistryConsumer (#443) @paulbakker
• Migrating to a ConfigurationProperties pattern compatible with SB 2.2 (#405) @berngp
• Explicitly nullable input arguments (#395) @paulbakker
• Adding an IntelliJ project icon (#394) @berngp

Additional Notes

Some DGS Client Components will move, soon, to the DGS Codegen project.

We are preparing to move the following components to the DGS Codegen project.
These artifacts are mainly used in the context of codegen. With the move we will hope to decouple
the codegen project from the DGS Framework releases. For now you can still use them but soon they will be deprecated
and after that removed:

• com.netflix.graphql.dgs.client.codegen.ProjectionSerializer
• com.netflix.graphql.dgs.client.codegen.GraphQLQueryRequest
• com.netflix.graphql.dgs.client.codegen.EntitiesGraphQLQuery
• com.netflix.graphql.dgs.client.codegen.InputValueSerializer
• com.netflix.graphql.dgs.client.codegen.BaseProjectionNode
• com.netflix.graphql.dgs.client.codegen.GraphQLQuery
• com.netflix.graphql.dgs.client.codegen.BaseSubProjectionNode

What does this mean for me?

For now things stay the same but, this will eventually affect you if you are using the graphql-dgs-client.
We will deprecate the components and provide you with additional instructions in the next release.

What’s Changed

• Migrating to a ConfigurationProperties pattern compatible with SB 2.2 (#405) @berngp
• Explicitly nullable input arguments (#395) @paulbakker
• Adding an IntelliJ project icon (#394) @berngp

What’s Changed

Support returning Mono/Flux from data fetchers (#389)

You can now return a Mono or Flux from a Data Fetcher. The framework will now transform a Mono or Flux object to a CompletableFuture automatically such that graphql-java can process its execution. Since graphql-java is already executing async this doesn't add any extra blocking.

New Metered Tags: gql.operation, gql.operation.name, gql.query.complexity, gql.query.sig.hash

The gql.resolver, gql.dataLoader, and gql.error timers will now express the following tags:

• gql.operation: QUERY, MUTATION, SUBSCRIPTION are the possible values. These represent the GraphQL operation that is executed.

• gql.operation.name: GraphQL operation name if any. There is only one operation name per execution. If the GraphQL query does not have an operation name, anonymous is used instead. Since the cardinality of the value is high it will be limited. More on how you can configure such limit below.

• gql.query.sig.hash: Query Signature Hash of the query that was executed. Absent in case the query failed to pass GraphQL validation. Since the cardinality of the value is high it will be limited. More on how you can configure such limit below.

Note, in addition we are changing the name of the qgl.queryComplexity tag to gql.query.complexity to better express that the complexity is a part of the query and be inline with gql.query.sig.hash tag.

The Query Signature, is defined as the tuple of the GraphQL AST Signature of the GraphQL Document and the Query Signature Hash. The signature of a query is defined as follows:

A canonical AST which removes excess operations, removes any field aliases,
hides literal values and sorts the result into a canonical query
Ref graphql-java

The Query Signature Hash is the Hex 256 SHA string produced by encoding the Query Signature. While we can't tag a metric by the Query Signature due its length, we can use the Query Signature Hash as now expressed by the gql.query.sig.hash tag.

New Configuration Properties

• management.metrics.dgs-graphql.query-signature.enabled: If true it will enable the calculation of GQL Query Signature. This will enable the tagging of gql metrics with the gql.query.sig.hash. A QuerySignatureRepositor component will also be available for container injection. It will be able to resolve a Document and InstrumentationExecutionParameters tuple to the QuerySignature. This can be useful if you want to leverage such object to add additional information to your Logs, Tracing Spans, etc.

• management.metrics.dgs-graphql.query-signature.caching.enabled: By default the calculation of the signature will be cached. You can turn this off by setting this property to false. Note that this will not turn the calculation of the signature off, it will just disable the cache. If you want to turn it off use management.metrics.dgs-graphql.query-signature.enabled.

• management.metrics.dgs-graphql.tags.limiter.limit: Defaults to100, sets the cardinality limit for the values of the gql.query.sig.hash and gql.operation.name tags. This limits the number of different values expressed in such tag, protecting the backing metric service form a cardinality explosion. The cardinality limit is per tag.

Improve error handling and null data semantics for entity fetchers. (#383)

DGS Entity Fetchers can now return null instead of creating an empty object that represents an entity. Previously, this would result in a DGSEntityNotFoundException with the following result, which was not compliant with federation spec:

{
  "errors": [
    {
      "message": "com.netflix.graphql.dgs.exceptions.MissingDgsEntityFetcherException: Missing @DgsEntityFetcher for type Movie",
      "locations": [],
      "path": [
        "_entities"
      ],
      "extensions": {
        "errorType": "INTERNAL"
      }
    }
  ],
data: null

The implementation is now returning the expected null entities array, for valid use cases where null data is expected :

{ 
  "data": {
    "_entities": [
      null
    ]
  }
}

We are also improving the handling of exceptions such that it allows us to return partial results. The exceptions errors are now populated for each entity as part of the error data in the result, along with an empty entities array as data. Previously, partial results were not being returned in case of exceptions. We can now get partial results along with the errors:

{
  "errors": [
    {
      "message": "java.lang.RuntimeException: Test entity exception",
      "locations": [],
      "path": [
        "_entities"
      ],
      "extensions": {
        "errorType": "INTERNAL"
      }
    }
  ],
  "data": {
    "_entities": [
      {
        "__typename": "Movie",
        "movieId": 1133,
        "fakeReviews": {
          "pageInfo": {
            "hasPreviousPage": false
          }
        }
      },
      null,
    ]
  }
}

Complete list of changes

• Support returning Mono/Flux from data fetchers (#389) @paulbakker
• Support returning Mono/Flux from data fetchers (#389) @paulbakker
• Metric tags gql.operation, gql.operation.name, gql.query.complexity, gql.query.sig.hash (#382) @berngp
• Improve error handling and null data semantics for entity fetchers. (#383) @srinivasankavitha
• Have the CI Gradle Build provide additional info (#386) @berngp
• Add Httpheader argument in executeAndExtractJsonPathAsObject (#372) @samhon
• Fix documentation for inclusivity. (#378) @srinivasankavitha
• Bump spectator-api from 0.130.+ to 0.131.0 (#387) @dependabot

What’s Changed

• Visibility of the MetricsInstrumentationState.tags method. (#390) @berngp
• Bump spectator-api from 0.130.+ to 0.131.0 (#387) @dependabot