i found a way to make a dataloader implementation for graphql-kotlin that allows using suspended fun...

# graphql-kotlin

[Lenny]

i found a way to make a dataloader implementation for graphql-kotlin that allows using suspended functions (based on an approach proposed by apollo) https://gist.github.com/lennyburdette/f3fe6ae7a498698774cc95d1bfc956b4 … would love some review/opinions!

[Shane Myrick]

cc @Dariusz Kuc

Hmm, interesting. The code looks pretty straight forward to me. Would users of graphql-kotlin have to manually call the dispatcher or would that be in the library?

PRs are always welcome! And we are start to branch to 4.x.x so we could introduce breaking changes if they were needed for the currently library

[Lenny]

so i’m manually creating the dispatcher around graphql.executeAsync , but i don’t have to manually emit values on the flow … that’s handled automatically by the wrapped dataloaders

[Lenny]

cool! i dunno if it makes sense to pull this into your libraries quite yet … i dunno how much work it would take to wire this up in graphql-kotlin-spring-server (we’re using jersey and wiring everything up manually) so figuring that out would probably driven some work

[Dariusz Kuc]

I think this is great but unsure whether we can easily integrate it

[Dariusz Kuc]

i.e. as you mentioned you explicitly wrap the graphql execution (currently handled in query handler) in that custom data loader so it kind of sounds like all or nothing scenario

[Dariusz Kuc]

we definitely should look into implementing some kotlin native query execution and drop the reliance on completable future

[Lenny]

yeah … and the gnarly part is that you have to pass the coroutine scope out of that wrapper for use in individual dataloaders

[Lenny]

yeah … a system with a real event loop would be way simpler and probably more efficient

[Dariusz Kuc]

got to find the time to finally do it 🙂

[Lenny]

just need a free weekend right? 😁

[Dariusz Kuc]

a free weekend? what is that?

[Joe]

Just seeing this now (was in #graphql but not #graphql-kotlin). This is a cool approach. I've ended up implementing the data loader futures as suspend functions (by passing a scope in the context a la https://github.com/ExpediaGroup/graphql-kotlin/pull/879 ), but having the resolvers still needing to return the CompletableFuture returned by the dataloader due to the executor hang you mention. might look at integrating your solution in my codebase at some point, but probably not soon. very cool though!