I might be wrong here, but I'm under the impression that this breaks the GraphQL specification.
I don't think GraphQL is supposed to continuously emit values on a single query. If RxJava is to be used, then the query should probably return rx.Single. Not sure if this is of any advantage since the proposed implementation already returns a Future as per spec.

I might be wrong here, but it seems that GraphQL future way of handling "reactivity" will be through the use of "subscriptions" (although not in the spec yet).

That said, maybe there's some space for a new "Reactive" spec definition. I'm actually interested in a way to do something similar but through an EventBus. In other words, client makes query to GraphQL endpoint and in turn, GraphQL submits queries to backend services that will respond directly to the client. Its more like a "fragment" to a query than a "subscription" to mutations.

I'm confused by

the proposed implementation already returns a Future as per spec

Where in the spec has Future been mentioned? Or do you mean the graphql-java impl?

Either case, seems to me like this reactive strategy would serve wonderfully as a backbone for implementing subscriptions in graphql-java.

@kaqqao, you are right, it does`t. But what I meant was that it seems that one of the goals in the java async implementation is to have it as close to the JS reference implementation as possible.

And that's what was done in #242

@bmsantos
Reactive vs. Futures is a very popular topic, especially in JS world (async/await vs. RxJS)

An advantage over futures is that it can optionally produce changes to the initial result. In fact, CompletableFutures are supported in graphql-java-reactive:
https://github.com/bsideup/graphql-java-reactive/blob/master/core/src/test/java/com/github/bsideup/graphql/reactive/AdaptersTest.java#L23

Reactive programming usually supersedes futures, because while Reactive Publisher is 0..n, CompletableFuture is 0..1. It means that if you use CompletableFutures/static values everywhere the resulting changeset will always contain at most 1 element without producing any changes.
But I like the flexibility of Reactive-aware executor under the hood so that when I want to produce changes I'll not refactor my code.

@bsideup, all true. I would rather have an interface based on RxJava, even if just rx.Single is returned in order to be closer to a Future behavior. I've used the current proposal for GraphQLAsync in Vert.x (simple example here) and one of the issues that I had is that not all Futures are created equal in Java. Vert.x, like Akka or Guava, has its own Futures implementation and the use of Java's CompletatbleFuture/CompletionStage will for the most part require some sort of translation from any of these other libraries.

In nowadays I pretty much convert everything async (rest calls, circuit breakers, etc) into an rx.Observable just because if makes development so much easier and "functional".

Unfortunately, that was not the path chosen by the GraphQL team but maybe there's space for improvement in this area. I mean, it might be an option to create a generic GraphQLAsync that can use different executors. Something like:

graphql = new GraphQLAsync<ExecutorType, OutType>(schema, new ExecutorType());
OutType result = graphql.executeAsync("query");

Like this one could use an RxJavaExecutor, a CompletableFutureExecutor, or whatever.

I don't think there's a hard decision yet, and that the current implementation is only a proposal. I might be totally wrong, thought.
Either case, having these alternatives proposals is very important/good as it may influence how subscriptions can/will be implemented. And there won't be a better time to discuss that than now.

@bmsantos
I'm all in for "async first" version of graphql-java!

In graphql-java-reactive I decided to support reactive Publisher and CompletitionStage by default, but there is adapt method to override:
https://github.com/bsideup/graphql-java-reactive/blob/master/core/src/test/java/com/github/bsideup/graphql/reactive/AdaptersTest.java#L45

This way data fetchers are able to return any type they want and the adapting is centralized and reused across all data fetchers :)