Here's a usage example:

final CompletionStage<ExecutionResult> future = new GraphQLAsync(schema,
    AsyncExecutionStrategy.parallel(new VertxCompletableFutureFactory(vertx))).executeAsync(query);

feature.handle((executionResult, throwable) -> {
  System.out.println("Result: " + executionResult.getData().toString());
  System.out.println("Errors: " + executionResult.getErrors().toString());
  System.out.println("Throwable: " + throwable);
  return this;
}).toCompletableFuture();

Where the factory class looks like:

public class VertxCompletableFutureFactory implements CompletableFutureFactory {

  private final Vertx vertx;

  public VertxCompletableFutureFactory(final Vertx vertx) {
    requireNonNull(vertx);
    this.vertx = vertx;
  }

  @Override
  public <T> CompletableFuture<T> future() {
    return new VertxCompletableFuture<>(vertx);
  }
}

This looks good to me! Thanks so much for the PR. Does this implementation look good to you, otherwise?

Yes, so far the implementation looks good. Still going through experimentation. Will keep you updated. Nice work.

Great, thank you. If you're familiar with Spock, there is also this spec.

Yes, I will eventually add some tests. I didn't so yet because the code introduced doesn't really change the inner works and the AsyncExecutionStrategy.serial() tests it with the DefaultCompletableFutureFactory.

It would be nice to add tests for parallel as well. I'll add some in the next few days.

Definitely. I have that @Ignored test regarding fields executing in the correct order. I left that as a reminder to ensure serial actually does switch to parallel after a mutation. But generally testing parallel mode as well will be good.

One more thing to maybe keep in mind is this: graphql-java#268.

Sounds good. Thanks for sharing.

I'm handling graphql-java#268 for this async version now. Will update here with new commit soon.

Quick update: I can now confirm that I've successfully used this implementation with Vert.x.

Parallel implementation seems to be working just fine. My case scenario looks something like this at this stage:

                    .---------.       .---------.
  POST /graphql --> | Vertx   |       | EP1     | 
                    | GraphQL | ----> | Swagger | 
                    | Server  |  |    | Server  | 
                    '---------'  |    '---------'
                                 |    .---------. 
                                 |    | EP2     | 
                                 '--> | Swagger | 
                                      | Server  | 
                                      '---------' 

EP1 is the main query data fetcher. EP2 is a endpoint that gets called in parallel for 3 different fields in the graph. All requests for EP2 are placed in parallel (in their own thread) to its respective endpoints.

So far so good. Everything is running non-blocking and no issues have been detected.

That is great to hear. I've never used Vertx or Swagger, but I'm glad you're abstracting over them (is what you'd call it?) with this implementation.

I pushed some commits to the async branch just now to fix some problems with error handling and the above-mentioned issue. Instead of squashing in force-pushing I did the opposite: the commits are small and hopefully easy to follow.

Looks like it's broken. One sec.

Ah, there we go. Should be good now graphql-java#283