chore(deps): update dependency com.graphql-java:graphql-java to v18 #427

renovate · 2022-03-15T17:02:59Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
com.graphql-java:graphql-java	`17.3` -> `18.0`

Release Notes

graphql-java/graphql-java

`v18.0`

We are happy to announce v18.0 of graphql-java

https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A18.0+is%3Aclosed

Applied Directives

Graphql directives have two modes. They can be defined in a schema

directive @&#8203;example on FIELD_DEFINITION | ARGUMENT_DEFINITION

and they can be applied to schema elements and query elements

type Query {
   field(arg : String! ) @&#8203;example

So we have a directive definition and cases where that directive is applied to an element.

However when the graphql.schema.GraphQLDirective and graphql.schema.GraphQLArgument classes was created, we modelled this badly. These classes should really represent a directive definition in schema only but we reused them to also be the representation of a directive and value arguments applied to another schema or query element.

This modelling is wrong. You can tell because we have javadoc comments like this in graphql.schema.GraphQLArgument saying a certain property is only applicable in certain call contexts.

    /**
     * This is only used for applied directives, that is when this argument is on a {@&#8203;link GraphQLDirective} applied to a schema or query element
     *
     * @&#8203;return an input value with state for an applied directive
     *
     * @&#8203;deprecated use {@&#8203;link GraphQLAppliedDirectiveArgument} instead
     */
    @&#8203;Deprecated
    public @&#8203;NotNull InputValueWithState getArgumentValue() {
        return value;
    }

So we have decided to fix this bad class modelling in version 18. We have introduced new classes

graphql.schema.GraphQLAppliedDirective
graphql.schema.GraphQLAppliedDirectiveArgument

which represent an applied directive on a schema element and

graphql.execution.directives.QueryAppliedDirective
graphql.execution.directives.QueryAppliedDirectiveArgument

which represent an applied directive on a query element

For backwards compatibility reasons, the old graphql.schema.GraphQLDirective objects are still created for applied elements however the methods have all been deprecated and like for like getAppliedXXX methods have been introduced.

You should migrate your code way from getting applied directives from the old methods and use the new more correctly modelled classes. This backwards compatibility will be removed in a future version.

Because of this backwards compatibility, there are a few gotchas to look out for. For example visitors will be called twice for the same applied element, eg one for the old style GraphQLDirective object and one for the new GraphQLAppliedDirective object. You should choose the new classes only as part of code migration. This should only affect code that does schema and query traversal (which is an advanced use case) and hence most consumers of graphql-java will not be affected.

There is one breaking change here. graphql.introspection.IntrospectionWithDirectivesSupport and its predicate argument graphql.introspection.IntrospectionWithDirectivesSupport.DirectivePredicateEnvironment have been changed to provide a directive name and not the appliedGraphQLDirective directly. Again we think very few people will be affected by this breaking change.

https://github.com/graphql-java/graphql-java/pull/2186

Dramatic performance improvement on Validation rules

The team at Twitter contributed a changed to the RulesVisitor that is used to validate a query against the set of validation rules. For large queries this could be a performance drag.

This changes it to roughly linear complexity and shows a 5000% speedup when validating our large queries.

https://github.com/graphql-java/graphql-java/pull/2563

Skipping validation rules

In extreme cases, a server may choose to skip certain validation rules. We don't recommend it, because results may become unpredictable and we won't support fixing issues caused by deactivated rules.

However it is now possible and may help trade validation for performance.

 Predicate<Class<?>> predicate = new Predicate<Class<?>>() {
            @&#8203;Override
            boolean test(Class<?> aClass) {
                if (aClass == NoUnusedFragments.class) {
                    return false
                }
                return true
            }
        }
        
ExecutionInput.newExecutionInput(query)
                .graphQLContext(["graphql.ParseAndValidate.Predicate": predicate])
                .build()

https://github.com/graphql-java/graphql-java/pull/2598

DataLoader has been upgrade

The java data loader version has been upgrade to 3.1.2 which as some bug fixes and small improvements.

https://github.com/graphql-java/graphql-java/pull/2724

`PreparsedDocumentProvider` changes

The graphql.execution.preparsed.PreparsedDocumentProvider has been updated to use a CompletableFuture<PreparsedDocumentEntry> getDocumentAsync method. This allows you to go to a remote cache in an asynchronous non blocking manner to get cached documents. This should have always been modelled in this manner.

However its an optional default interface method thats called the old deprecated synchronous method direct.

https://github.com/graphql-java/graphql-java/pull/2612/files