Replies: 2 comments 4 replies
-
|
Thanks to all involved for the hard work! |
Beta Was this translation helpful? Give feedback.
-
|
Will I'm asking because in graphql-java-tools we use a copy of this helper class to handle wiring directives for us. Obviously this is not good practice so I'm hoping this could be our chance to fix it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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
and they can be applied to schema elements and query elements
So we have a directive definition and cases where that directive is applied to an element.
However when the
graphql.schema.GraphQLDirectiveandgraphql.schema.GraphQLArgumentclasses was created, we modelled this badly. These classes that should really represents 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.GraphQLArgumentsaying a certain property is only applicable in certain call contexts.So we have decided to fix this bad class modelling in version 18. We have introduced new classes
graphql.schema.GraphQLAppliedDirectivegraphql.schema.GraphQLAppliedDirectiveArgumentwhich represent an applied directive on a schema element and
graphql.execution.directives.QueryAppliedDirectivegraphql.execution.directives.QueryAppliedDirectiveArgumentwhich represent an applied directive on a query element
For backwards compatibility reasons, the old ``graphql.schema.GraphQLDirective
objects are still created forapplied` 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
GraphQLDirectiveobject and one for the newGraphQLAppliedDirectiveobject. 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.IntrospectionWithDirectivesSupportand its predicate argumentgraphql.introspection.IntrospectionWithDirectivesSupport.DirectivePredicateEnvironmenthave been changed to provide a directive name and not the appliedGraphQLDirectivedirectly. Again we think very few people will be affected by this breaking change.#2186
Dramatic performance improvement on Validation rules
The team at Twitter contributed a changed to the
RulesVisitorthat is used to validate a query against the set of validation rules. For large queries this could be a performance drag.#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.
#2598
DataLoader has been upgrade
The java data loader version has been upgrade to
3.1.2which as some bug fixes and small improvements.#2724
PreparsedDocumentProviderchangesThe
graphql.execution.preparsed.PreparsedDocumentProviderhas been updated to use aCompletableFuture<PreparsedDocumentEntry> getDocumentAsyncmethod. 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
AstPrinterperformanceThe AST printer has been improved to stop unnecessary string allocation. For very large queries this slowed printing down dramatically.
#2729
Local context and field selection in TypeResolutionEnvironment
The type resolvers now can get access to the local context object via the passed in
graphql.TypeResolutionEnvironmentinterface.Similarly, the field sub selection
graphql.schema.DataFetchingFieldSelectionSetis also now available.#2699
#2597
Auto generated list of What's Changed
SchemaPrinter. by @folone in Sort schema directives inSchemaPrinter. #2575Introspection.__DirectiveLocationregression tests by @jord1e in Fix gh-2702 and addIntrospection.__DirectiveLocationregression tests #2703SchemaPrinter(\r\n -> \n) by @jord1e in Fix wrong newline on Windows inSchemaPrinter(\r\n -> \n) #2705@DeprecatedtoExecutionStepInfo#getFieldContainer()by @jord1e in Add missing@DeprecatedtoExecutionStepInfo#getFieldContainer()#2712New Contributors
SchemaPrinter. #2575Full Changelog: v17.3...v18.0
This discussion was created from the release 18.0.
Beta Was this translation helpful? Give feedback.
All reactions