A modern programming language that makes developers happier.

kotlinlang

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!

cc <@UGUMP8USE>

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

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

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

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

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

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

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

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

got to find the time to finally do it :slightly_smiling_face:

Just seeing this now (was in <#CKD2KL89G|graphql> but not <#CQLNT7B29|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!