Bot releases are visible (Hide)
Published by andimarek over 6 years ago
This is a bugfix release to address mainly the following things:
#1102: This fixes mutation when used with the batched data loader instrumentation.
#1090: This fixes chained instrumentation.
#1072: Not consistent exception handling across strategies
The full list of changes can be found here:
https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A9.1+is%3Aclosed
Published by bbakerman over 6 years ago
The performance of graphql.execution.instrumentation.dataloader.DataLoaderDispatcherInstrumentation
has been greatly improved. It now tracks which fields are outstanding and how many values are expected for that field. This allows it to optimise when it "dispatches" the underlying data loaders so that they retrieve as much data as possible in one call.
PR: https://github.com/graphql-java/graphql-java/pull/990
The new graphql.schema.idl.SchemaDirectiveWiring
interface allows you to wire in new behaviour to the SDL built graphql schema via directives that are placed on SDL types and fields.
For example imagine a type such as the following
directive @auth(role : String!) on FIELD_DEFINITION
type Employee
id : ID
name : String!
startDate : String!
salary : Float @auth(role : "manager")
}
You can now wire in data fetcher behaviours that enforce the authorisation access to those specific fields.
PR: https://github.com/graphql-java/graphql-java/pull/1001
If you use a directive in the schema, you now MUST declare it up front and on what places it can apply. This is required by the graphql specification. eg:
directive @length(max: Int = -1) on FIELD_DEFINITION | INPUT_FIELD_DEFINITION
There is an boolean flag that allows you to use the old lenient behaviour but its off by default.
PR: https://github.com/graphql-java/graphql-java/pull/1006
The default and most called data fetcher graphql.schema.PropertyDataFetcher
has been optimised to make it run faster. It now caches method look ups so that the costs of reflection is not paid over and over
PR: https://github.com/graphql-java/graphql-java/pull/1013
It is now considered a supported operation in graphql-java.
PR: https://github.com/graphql-java/graphql-java/pull/1035
QueryTraverser
is a new traverser for Documents (or part of it) which tracks at the same time the type
informations of the Schema. It is intended to be used for advanced use-cases including libraries build on top of graphql-java.
PR: https://github.com/graphql-java/graphql-java/pull/1031
See the following Pull Requests for more information on other changes v9.0
Published by bbakerman over 6 years ago
This release contains a number of fixes, enhancements and breaking changes.
The list of breaking changes can be found here
The graphql SDL specification has finally hit master at Facebook and graphql-java has reflected this.
https://github.com/facebook/graphql/blob/master/spec/Section%203%20--%20Type%20System.md
One new capability is that you can now extend all the different types not just Object types, which includes Interfaces, Unions, Enums, Scalars and Input Objects.
interface NamedEntity {
name: String
}
interface ValuedEntity {
value: Int
}
type Person implements NamedEntity {
name: String
age: Int
}
type Business implements NamedEntity & ValuedEntity {
name: String
value: Int
employeeCount: Int
}
extend interface NamedEntity {
nickname: String
}
extend type Person {
nickname: String
}
extend type Business {
nickname: String
}
See:
#933
#935
#941
#945
You can specify directives during SDL type definition and these have now been captured and transferred to the graphql runtime types.
So for example given
type Person implements NamedEntity {
name: String
age: Int
wage : Int @security(role:"manager")
}
The special directive security
will be made available on the wage
field.
GraphQLDirective securityDirective = personType.getField("wage).getDirective("security")
See
#924
#923
The graphql.execution.instrumentation.Instrumentation
SPI has been significantly changed. graphql-java uses an asynchronous model to execute a query and Instrumentation
and InstrumentationContext
has been changed to reflect that.
The signature of the methods have been changed to reflect that instrumentation callbacks now happen in two phases. The first is when the engine first dispatches an operation step and then again when it asynchronously completes.
public interface InstrumentationContext<T> {
/**
* This is invoked when the instrumentation step is initially dispatched
*
* @param result the result of the step as a completable future
*/
void onDispatched(CompletableFuture<T> result);
/**
* This is invoked when the instrumentation step is fully completed
*
* @param result the result of the step (which may be null)
* @param t this exception will be non null if an exception was thrown during the step
*/
void onCompleted(T result, Throwable t);
}
This is a breaking change to code that has implemented Instrumentation
. You will have to change the code to implement this double callback pattern.
See #894
You can now specify an alternative name to fetch property values from during SDL type declaration
type Invoice {
id : ID
invoiceDate : String @fetch(from:"whenInvoiced")
}
This allows indirection between the names you want to use in a graphql schema and the backing Java data
without having to write this mapping logic into all your data fetchers.
You can now support a deferred execution of parts of a query via @defer
directive.
(This is an experimental feature, it is currently not part of the official spec.)
https://github.com/graphql-java/graphql-java/pull/967
The graphql spec is not super clear on whether multiple errors are allowed per field during execution. The previous code took the approach that they are not. However a re-interpretation of the specification reveals that is only true for null field checks.
So the restriction has been lifted and you can have multiple errors per field (except for null checks during execution)
See
#895
Our friends from Intuit have contributed a series fo fix to help with the performance of the graphql-java engine during schema type look up, which happens a lot during the execution of a query.
See #898
graphql.execution.batched.BatchedExecutionStrategy
has been deprecated as an execution strategy.
It does not follow the graphql specification correctly and it has challenges on deeply nested queries with stack overflows being possible. While it remains in the code base, it may be removed at a later time.
See : #965
The rest of the PRs for 8.0 can be found by following this link
https://github.com/graphql-java/graphql-java/pulls?utf8=%E2%9C%93&q=is%3Apr+milestone%3A8.0+
Published by bbakerman almost 7 years ago
This release contains a number of fixes and enhancements
This will report not just API breaking changes but additions (new fields / arguments etc..) as well
See #870
The original subscription support didn't not send back the top level field which was contrary to the graphql specification. This is now fixed
See #850
You can now used field visibility to decide what fields are available on input types as well as output types
see #854
Published by bbakerman almost 7 years ago
This release includes several improvements and bug fixes.
The big ticket item of 6.0 is support for graphql subscriptions. A subscription is a stream of results sent out by applying a graphql query over changing results.
This explains more : http://graphql.org/blog/subscriptions-in-graphql-and-relay/ in a general sense.
The graphql-java support is based on returning a reactive stream of ExecutionResult
. Each time something changes on the subscription a new ExecutionResult
is sent down to the Subscriber
.
Systems like RxJava have support for the http://www.reactive-streams.org/ interfaces and with Java 9 you can write trivial adaptors to turn reactive stream Subscriber
s into Java 9 Flow.Subscribers
s
See #754
The efficiency of data loader has be improved. Before it was too eager is calling dispatch which meant that lists of data cause early dispatches. The code has improved to handle this and the data loader batching is delayed into the last possible moment, greatly increasing the batching efficiency
See #764
In line with the reference graphql-js implementation, validation and coercion problems are reported as errors and not exceptions.
See #789
The Apollo Tracing spec was updated to include timings for parsing and validation and this is now reflected correctly.
See #784
A small API enhancement to make it easier to use the TypeResolution class as well as the ability to override the exceptions from the query complexity checkers.
There is also more data available via the TypeResolutionEnvironment class.
There is also a new AsyncDataFetcher to help compose asynchronous data fetchers.
See #774
See #778
See #795
See #798
Published by andimarek about 7 years ago
This release includes several bugfixes and improvements.
The most important strategic change is #704: We now include java-dataloader
as a direct dependency to make it as easy as possible to tackle performance issues during complex queries.
This also means java-dataloader
is now a first class citizen in the graphql java world and will be maintained and improved on the same level as graphql-java
.
We also reverted an older change to be graphql specification compliant again regarding InputObjects variables: #750. We expect that some users may have a problem with that. Please open an Issue if that is the case and we will find a solution.
Other notable changes are:
#690: pluggable field validation
#735: DataFetcher factories to allow for better IoC support of data fetchers
#745: diff two schemas
#747: Fix validation of non-null Interface member
#738: more logging of query execution
#708: allow different directives on the same field
#678, #696, #697 : Batched ExecutionStrategy fixes
#681: Support for primitive arrays as a return value for Lists
#679: Support for Iterables for as a return value for Lists
For a full list of issus/PR see here.
Published by andimarek about 7 years ago
This is bugfix release containing these changes:
https://github.com/graphql-java/graphql-java/milestone/8?closed=1
Published by andimarek about 7 years ago
This release is a bugfix release for 4.0 with one single PR:
#666: the new QueryTraversal
class didn't work with mutations or subscriptions.
Please see here for the full 4.0 release notes: https://github.com/graphql-java/graphql-java/releases/tag/v4.0
Published by andimarek about 7 years ago
Thanks a lot to all contributors for reporting bugs, giving feedback, fixing bugs, adding new features and more!
#590
This is the biggest enhancement to come to graphql-java in a long time. Query execution is now performed in a fully asynchronous manner. A DataFetcher
is now able to return a CompletionStage<Object>
background promise to data and the graphql-java engine will ensure that when it completes it will be placed into the correct place in the query results.
This allows you to use facilities like java 8's CompletableFuture.supplyAsync()
to run many data fetchers in parallel, which should improve the speed of your system by fully utilizing all your available CPUs.
All of the provided ExecutionStrategy
implementations now support fully asynchronous results. Note if you have your own derived ExecutionStrategy
then the method signatures have been modified and are described below in the breaking changes section.
#577
New TracingInstrumentation
has been added that tracks how long each field takes to execute. This is reported back on the ExecutionResult
extensions field and gives you insight into how you graphql-java server is performing.
This tracing support follows the proposed Apollo Tracing specification https://github.com/apollographql/apollo-tracing which can then be viewed via their Optics performance monitoring tooling : https://www.apollodata.com/optics/
#641
You can now control the visibility of selected fields in the schema. A GraphqlFieldVisibility
implementation can be attached to a schema that decide on what fields will be made visible to queries and introspection. This allows you to say restrict the view of the schema for different classes of users say.
#625
java.util.Optional
is now supported as a return value from data fetchers and will be collapsed into either an object or the null value in graphql terms.
#618 #575 #560
Instrumentation
was enhanced significantly to with an extra method when an ExecutionStrategy
is entered and exited. It also allows you to intercept DataFetcher
s and results and hence inject new behaviour into the running system.
#616
The error messages for argument validation have been improved and better tells you went wrong and in more detail.
#650
You can now store extra meta data on GraphqlError
objects that can be sent back to your client code
#552
The ExecutionResult
object now has a toSpecification()
method that gives you back and object that 100% complies with the graphql specification.
#449
There is now "path" support when running queries. Errors contain the path to which field was in error in a structured specified by the graphql specification and DataFetcher
s also get this path information.
#467 #470 #468
Schema IDL has been improved. Any additional types defined in schema IDL are now included into the build GraphqSchema
object as expected, deprecation is now supported via IDL files and the build runtime type objects contain the original AST definitions.
#593:
Instrumentation
callback is now one method (with two parameters) instead of two methods.#590 #380 #542 #487:
ExecutionStrategy
has been refactored by several PRs but it affects only custom strategies.CompletableFuture
.#550:
ExecutionStrategy.handleDataFetchingException
is removed: Instead a delegate DataFetcherExceptionHandler
is used to handle Exceptions.#211 #456 :
An explicit root
Object is added which is available to DataFetchers and is the source
for the first level DataFetcher
. Before that context
was used for that purpose. Note: GraphQL.execute(String query, Object context)
is still compatible to avoid unexpected bugs.
The arguments objects for the Instrumentation
are renamed to make them more clear: E.g. DataFetchParameters
-> InstrumentationDataFetchParameters
#455:
#427:
null
literal the result of not providing an argument to a field was changed: not providing an arguments results in a arguments Map (for the DataFetcher
) with no key in it and providing the null
literal results in a Java null
values.#660:
See here for the full list of all changes.
Published by andimarek over 7 years ago
This is our biggest release yet, with exciting new features, but also with breaking changes.
A big thanks to all contributors! A lot of them are not directly mentioned here, but every comment or Issue makes this project better.
The most fundamental change is that graphql-java
requires now Java 8. Java 6 or Java 7 is no longer supported. (#359)
The biggest new feature is that we now offer a second way to define a schema (#386).
#395: TypeResolver:
The TypeResolver
Interface was changed from getType(Object object)
to getType(TypeResolutionEnvironment environment)
. The object previously directly passed is now available as TypeResolutionEnvironment.getObject()
.
#398: GraphQLSchema:
GraphQLSchema.getDictionary()
was renamed to getAdditonalTypes()
#400: Type References:
GraphQLObject.reference()
, GraphQLInterfaceType.reference()
and GraphQLInputObjectType.reference()
has been removed: Instead instantiate a new GraphQLTypeReference()
.
#401 FieldCollector:
The FieldCollector
class is now clearly marked as an internal class and was changed. It is very unlikely that you used this class. If you did: please open an Issue to adress your use case.
Published by andimarek over 7 years ago
Changes:
Big thanks to all contributors!
Info: This is last release supporting Java 6. The next release will require Java 8 and will probably contain other breaking changes. (Version 3)
Published by dminkovsky almost 8 years ago
Release highlights
This release also includes a test improvement (#196) and documentation fix (#246).
Big thanks to all contributors!
Published by dminkovsky almost 8 years ago
Release highlights
This release also includes code cleanup (#201, #234, #216) and documentation (#228).
Published by andimarek about 8 years ago
Release highlights
This release also includes code cleanup (#191, #185, #141, #121, #117, #120), documentation (#119, #158, #131) and test improvements (#133).
Published by andimarek over 8 years ago
This is version 2.0.0 of graphql-java:
GraphQLFloat
was changed to return Java double values instead of Java float values in order to comply with the spec.Thanks a lot to all contributors, who created a PR/Issue!
Published by andimarek almost 9 years ago
mainly bugfixes and a first very basic relay support
Published by andimarek about 9 years ago
This release contains:
ExecutionResults
)com.graphql-java
to comply with maven-central requirements