So graphql-java does support reactive streams for its graphql subscriptions support. A subscription in graphql-java is a Publisher of event objects that are matched to a graphql subselection.

That said you seem to be talking about allow "reactive streams" to be used in a query | mutation. Your right that the engine is not reactive streams aware in itself. Its is based on CompletableFuture - we did this because of history (java 8 based until recently) and to reduce the dependencies that graphql-java requires.

But I have evidence that it does not have to be a pure reactive programming model to be used in a reactive world.

I work at Atlassian and we have a lot of graphql-java based systems that are running in Spring WebFlux / Reactor code bases- that is a reactive streams programming model.

They work in a truly async way and scale really well. A Mono can always be turned into CompletableFuture and in fact ships with helper methods to do so

DataFetcher asyncDF =  environment -> {
        Mono<Data> mono = webClient.get().retrieve().bodyToMono(Data.class);
        CompletableFuture<Data> dataCF = mono.toFuture();
        return dataCF
}

The above is complete async but technically not fully reactive because the back pressure is in theory missing but back pressure is more about Flux and not Monos. And a graphql data fetch is always a Mono - eg single future value.

	public final CompletableFuture<T> toFuture() {
		return subscribeWith(new MonoToCompletableFuture<>(false));
	}

the toFuture() creates subscriber that completes the CF when the mono completes - as simple as that.

a situation where fetchers involve HTTP requests..... discrepancy between wait and work times is hindering thread utilization and overall performance.

transform the subscription to a future but that nulled the whole purpose of the switch as we had to move contexts between two different parallel models adding latency, memory usage, and more complexity.

I don't see how - I mean I cant see your code so I am talking in a general sense.

The Mono.toFuture adds a subscriber to a Mono and allows the processing stays async - I dont see how this adds latency or excessive memory usage. A pure reactive engine would require a subscriber on data fetches say.

I will agree that it does add some complexity but I dont think its overwhelming - yes you need to mono.toFuture() in your data fetchers but all the code that leads to the final data fetched value can bve as reactive as you like. You can use all their operators to compose that fetch to your hearts content.

One idea to improve it was to replace the thread pool with a reactive stream model

So this hints at something - but I am not sure what - because I cant see your code - but a reactive system like Project Reactor does indeed have a thread pool behind it - its those threads that are servicing the event loops in reactor code when callbacks happen after IO - so while you might not be managing them per se (although in advanced cases you can) they are there.

If we did have an engine that supported reactive streams it would in fact be a completely new engine - reactive streams (like CFs) are viral and need to be used at all points in the code to be effective. Callback code like DataFetchers and Instrumentation would all need to be written with reactive in mind

Finally Spring has chosen to use graphql-java for https://docs.spring.io/spring-graphql/docs/current/reference/html/ and this works quite well in their WebFlux (aka Project Reactor) reactive code bases - they use mono.toFuture() under the covers

https://docs.spring.io/spring-graphql/docs/current/reference/html/#execution.reactive-datafetcher

In fact they have solved one of the complexity challenges that I acknowledge up above and thats propogating Spring reactor context to data fetchers. So I would urge you to consider looking at Spring Graphql + WebFlux say.

If we were to make a whole new engine - we would likely SKIP reactive and move to Project Loom threads where each data fetch would use a a new Fiber for each fetch say and the system would appear sync but act asynchronously. We have done a very early proof of concept on this - nothing production ready but we have explored it.

https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html