https://kotlinlang.org
Join Slack
I'm using ```graphql-kotlin``` together with a webserver called Armeria that has support for graphql...
# graphql-kotlin
t
I'm using
Copy code
graphql-kotlin
together with a webserver called Armeria that has support for graphql-java (and an example for graphql-kotlin). The problem is that there is no way to get the 
RequestContext
in suspend functions, nor to use the Dispatchers provided by Armeria in an easy way. I've solved it by extending and overriding methods in 
FunctionDataFetcher
. It seems that 
runSuspendingFunction
has parameters for at least 
CoroutineContext
, so does that mean there are plans for greater configurability? E.g. by allowing the specification of a 
CoroutineContext
in the constructor of 
FunctionDataFetcher
or something similar? I doubt the problem is unique to Armeria, since I can't figure out how to pass the context through to suspending methods without byte-code instrumenting graphql-kotlin runtime?
Just some context: Since Armeria is primarily a java server 
RequestContext
is available through a wrapped ThreadLocal, but has extensions to invoke suspend functions, turning the RequestContext into a context element.
d
TLDR since we rely on 
graphql-java
execution logic, we are constrained with what we can do with Coroutines due to the 
graphql-java
dependency on 
CompletableFuture
looks like Armeria has its own mechanism for propagating the context so you would need to create custom 
FunctionDataFetcher
that incorporates that logic
for your use case -> probably it would be the easiest to just override 
runSuspendingFunction
in your custom data fetcher so it reads stuff from armeria context
t
Yup, sorry, I see that I missed saying that I've already done that in my code. Now the problem is doing it in a more stable way
My question is more in the form of "Can the CoroutineContext be exposed as a constructor argument in e.g. SimpleKotlinDataFetcherFactoryProvider and propagated to the FunctionDataFetcher and finally into 
runSuspendingFunction
I would assume that it would be useful for more than me to replace the GlobalScope's Default Dispatcher with their own Dispatcher, same with the ability to propagate webservers context.
d
you can create your own factory provider that injects some context
underlying issue is the same -> when we switch between completable future and coroutines we break structured concurrency
t
Absolutely
d
"proper" fix would be to rewrite the execution logic so it is coroutine aware so then you have proper parent - child relationship
j
we did some initial work that I think relates this here: https://github.com/ExpediaGroup/graphql-kotlin/pull/879 but not merged due to some cases not being handled around proper parent-child relationship. might be useful or not
t
I think there may be a misunderstanding here. Armeria is not calling from a coroutine. It's calling from graphql-java normal vanilla code on certain Executors
What I want is to inject my own context with a custom dispatcher using their blocking threads pool as the context everything is launched on
and also where I can prepare some context element magic to propagate the RequestContext attribute (which is a normal java class)
Which I can do fine by overriding the methods in the DataFetcher
What I was hoping for is that the CoroutineContext variable could be set in the constructor since it seems (to me) like a common problem
Let's see if I can make a PR
d
but that again should be a custom code and not part of SDK
t
Yes, but I believe the SDK could be more helpful without adding clutter. I've added a PR that you can reject without any comment if you don't like it, but just so I'm not being misunderstood: https://github.com/ExpediaGroup/graphql-kotlin/pull/1247
I'll shut up now 😃
33 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by