@bbakerman bbakerman released this Oct 20, 2018 · 33 commits to master since this release

Assets 2

Breaking changes

#1263 - DataLoader Scope changes

The dataloader support in graphql-java has been changed to encourage the right behavior. The DataLoaderRegistry and its contained DataLoaders need to be per execution instance based. However the previous setup made them tied to schema which is typically shared across executions.

Instead now the DataLoaderRegistry is specified as a property of the ExecutionInput and hence definitely per execution. This ensure thats the behaviour of data loader is scope to one execution and only one execution.

#1269 #1275 #1276 #1277 - ExecutionTypeInfo changed

These PRs are all somehow related.
The main change is that we renamed ExecutionTypeInfo to a more semantically correct ExecutionStepInfo since it contains much more information than just type information and it is actually focused around the current step of the execution.
We also changed the meaning of ExecutionStepInfo.type for non nullable types: previously it has been automatically unwrapped so that type was never NonNull.
If you used .getType() please change it to .getUnwrappedNonNullType() to avoid any logic changes.

Also castType was removed (just do the cast yourself if needed) and treatAs was renamed to changeTypeWithPreservedNonNull.

Other changes

#1269 - data fetchers can get their parents arguments

Sometimes a child data fetcher wants to lookup upwards and know what arguments are passed to its parents. This is now supported via the ExecutionStepInfo class. You can get the parent ExecutionStepInfo from the current field ExecutionStepInfo and also gets its arguments.

#1213

Directives are now considered children of graphql types and will be visited like other children. This allows you to write Traversals that find directives on graphql type objects and apply certain behaviours.

#1264 default methods on interfaces can now supply values to the property data fetcher

#1255 a possible deadlock in the data loader instrumentation tracking was fixed when DataLoader is not per execution

#1243 all the older BatchedExecutionStrategy code is deprecated. Use the DataLoader pattern instead

#1222 The handling of __typename was fixed that caused problems in max query complexity

#1203 the field paths now using the field alias of defined as the path name. This is more correct and specific.

All PRs can be seen here : https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A11.0

@bbakerman bbakerman released this Sep 3, 2018 · 83 commits to master since this release

Assets 2

Breaking Change: Ast Nodes

The biggest breaking is the mutability and the general design of Ast Nodes:

  • Every Node has now a Builder and aims to be immutable
  • Nearly every getter for a collection returns now a copy instead of the real collection

Background:

Ast Nodes have never really been part of the public Api, but they "sneaked" into it again and again over time (for example you can get the Field from the DataFetchingEnvironment). So it was time to really support it: we refactored them and made them immutable. Unfortunately because of some external dependencies on the mutability we didn't go all the way: some Nodes are still mutable. We aim for making it fully immutable in the future.

WARNING: If you rely on the mutability of the Ast you have to refactor your code! Especially getter returning now a copy of collections and modifications of it doesn't have any effect!

Other breaking changes:

#1130: QueryVisitorFieldEnvironment.getParentType() returns now the possible modified type and not the unmodified type.

#1133: TypeDefinitionRegistry.add now accepts only SDLDefintion

#1145: A small change around additonalTypes if you use the GraphqlSchema constructor directly

PropertyDataFetcher methods can receive an DataFetchingEnvironment object

See #1169

The invoked POJO method can now take the DataFetchingEnvironment as an argument which helps to make ever more light weight data fetching code.

DataLoader has been bumped to 2.1.1

The new DataLoader version allows new types of batch loading functions to be written and includes return a Map of results instead of an ordered list. They also allow context to be passed to help wire in things like user credentials and so on.

Ability to get field sub selections more easily

DataFetchingFieldSelectionSet has been improved making it easier to look at field sub selection and therefore optimise your data fetching queries.

For example a Relay system might have code like the following to help find out what data they want.

List<SelectedField> nodeFields = selectionSet.getFields("edges/nodes/*");

See #1176

ExecutorServiceExecutionStrategy has been depreacted

There is no need to use ExecutorServiceExecutionStrategy anymore since all its functionality can be replicated in data fetchers by calling CompletableFuture.supplyAsync(() -> someValues(), executor)

This will be removed in a future version

You now have the ability to navigate up the execution tree in terms of fields

Previously ExecutionTypeInfo created an execution tree of types but not the AST fields. This has been added, allowing a data fetcher to look upwards towards parent fields.

See #1176

Tons of other fixes

https://github.com/graphql-java/graphql-java/pulls?utf8=%E2%9C%93&q=+is%3Apr+milestone%3A10.0+

9.3

@bbakerman bbakerman released this Sep 3, 2018 · 4 commits to 9.x since this release

Assets 2

This is a bugfix release to address mainly the following things:

#1191 race conditions in data loader dispatching
#1182 fix null element
#1150 class cast exception in schema generation
#1142 validate input variables
#1113 npe in field tracking during dispatch
#1159 fix json encoding of values

See https://github.com/graphql-java/graphql-java/pulls?q=is%3Apr+milestone%3A9.3

@andimarek andimarek released this Jul 17, 2018 · 11 commits to 9.x since this release

Assets 2

This releases fixes a single regression from 9.1:
#1118

@andimarek andimarek released this Jul 10, 2018 · 165 commits to master since this release

Assets 2

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

@bbakerman bbakerman released this Jun 5, 2018 · 188 commits to master since this release

Assets 2

Data Loader performance has been greatly improved

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: #990

Directive Wiring Support

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: #1001

Directives MUST be declared in the schema

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: #1006

PropertyDataFetcher has been optimised

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: #1013

@defer support is no longer experiemental

It is now considered a supported operation in graphql-java.

PR: #1035

New Traverser for analyzing queries:

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: #1031

More

See the following Pull Requests for more information on other changes v9.0

@bbakerman bbakerman released this Mar 23, 2018 · 277 commits to master since this release

Assets 2

This release contains a number of fixes, enhancements and breaking changes.

The list of breaking changes can be found here

Extend all the SDL types

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

Directives on runtime types

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

Instrumentation

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

@fetch directive has been added to SDL

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.

Experimental support for deferred execution

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.)

#967

The ability to have more than one error per field

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

Performance improvements during type look up

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

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

Other changes and fixes

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+

@bbakerman bbakerman released this Jan 11, 2018 · 452 commits to master since this release

Assets 2

This release contains a number of fixes and enhancements

The schema diff now reports additions

This will report not just API breaking changes but additions (new fields / arguments etc..) as well

See #870

The root object of the subscription is correctly returned

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

Input types can now have field visibility

You can now used field visibility to decide what fields are available on input types as well as output types

see #854

Other changes

@bbakerman bbakerman released this Nov 6, 2017 · 507 commits to master since this release

Assets 2

This release includes several improvements and bug fixes.

Subscription support

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 Subscribers into Java 9 Flow.Subscriberss

See #754

Performance of Data Loader

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

Validation problems are now errors not exceptions

In line with the reference graphql-js implementation, validation and coercion problems are reported as errors and not exceptions.

See #789

Tracing Support now has parsing and validation timings

The Apollo Tracing spec was updated to include timings for parsing and validation and this is now reflected correctly.

See #784

API enhancements

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

Other fixes include