Proposal for Reactive Streams Integration in graphql-java #3308
Replies: 1 comment 5 replies
-
|
So graphql-java does support reactive streams for its graphql That said you seem to be talking about allow "reactive streams" to be used in a 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 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. the
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
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your thorough response, Brad.
I did look into using Mono and the issue I encountered was related to the latency I mentioned.
The new virtual threads are a great replacement for the current kernel threads we are using, but I am curious about the need for a new engine. Correct me if I am wrong, but isn't one of the goals of virtual threads to replace the current threads without the need to have any major rework? |
Beta Was this translation helpful? Give feedback.
-
|
The virtual thread will require a jdk21. And Mono is mostly running from the same thread, so I don't think there will be much latency. |
Beta Was this translation helpful? Give feedback.
-
yes - it's a long way off possible in many regards since graphql-java tries to target low JVM requirements - we only just moved Java 11. |
Beta Was this translation helpful? Give feedback.
-
The reason you would need a new engine (for EITHER reactive streams or for virtual thread fibers) is that the programing model becomes viral
The current engine itself is all based on CompleteableFuture composition - so while the graphql algo stays the same (get fields on source object / descend / get fields on source object) the impleementation is very different The spikes we have done have shown how its very different |
Beta Was this translation helpful? Give feedback.
-
how big are we talking here - I am having trouble imagining this to be a problem - we have Spring trace context and other things in our code base being copied into MDC maps all the time and its never shown up as perf problem (and trust me out code is often highly optimised - at least its highly examined) Are you copying megabytes of context? Anyway this is more about your code and not graphql-java. All code base have unique challenges |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello all,
I hope this message finds you well.
The idea is to introduce support for reactive streams within graphql-java. This would open the door to a subscription model without worrying about Using the CompletableFuture or any type of conversion.
Allow me to provide some context regarding the issue:
My current project is using graphql-java 17.3 and I've encountered a situation where fetchers involve HTTP requests with varying latencies, while subsequent data processing is comparatively quick. This discrepancy between wait and work times is hindering thread utilization and overall performance.
One idea to improve it was to replace the thread pool with a reactive stream model, but the blocker was that the available execution strategy works with CompletableFuture. One workaround was to 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.
if there was support for reactive programming, that would help immensely in such cases. I'm eager to hear your thoughts on this idea. I greatly value your insights.
Beta Was this translation helpful? Give feedback.
All reactions