Open fpetwo opened 1 month ago
use the coroutine scope from the graphQLContext which is located in the dataFetchingEnvironment, most of the time you DO NOT need to explicitly run coroutines in parallel, the coroutines state machine is smart enough to decide if a new thread needs to be use to launch a new coroutine.
I also did a bit of further research:
The coroutine scope in the dfe
is the parent scope of the scope that the resolver functions run in. So, the Job
object in kotlin.coroutines.coroutineContext
is the child of the Job
object in (dfe.graphQlContext.get(CoroutineScope::class) as CoroutineScope).coroutineContext
.
If you need to start something that truely runs in parallel, i.e. return early with the response to the client but keep working on something on the server, you have to use a different scope; not the one mentioned above. Because both scopes/jobs/contexts have a lifetime that is bound to the handling of this one graphQL call; i.e. they are not suited to start something that runs longer than the call handling.
I think https://api.ktor.io/ktor-server/ktor-server-core/io.ktor.server.application/-application/index.html is good option for something like this.
I have the resolver shown below. It can access its current
CoroutineContext
object but also anotherCoroutineContext
object via theDataFetchingEnvironment
.These two
CoroutineContext
objects are not the same.The documentation states:
(https://opensource.expediagroup.com/graphql-kotlin/docs/schema-generator/execution/async-models#structured-concurrency)
Do I understand it correct that I should use the
CoroutineContext
from theDataFetchingEnvironment
to start a new coroutine and NOT the given currentCoroutineContext
object?Which coroutine context or better coroutine scope should I use, if I would like to start a coroutine in parallel so that the response goes back immediately without waiting for the result? Does it still make sense to use this scope: https://api.ktor.io/ktor-server/ktor-server-core/io.ktor.server.application/-application/index.html?