# graphql-kotlin


05/14/2020, 5:42 PM
looking through some old threads here, i’m seeing that expediagroup doesn’t use dataloader — do y’all have another solution to the N+1 query problem? i’d be happy to drop dataloader if possible

Shane Myrick

05/14/2020, 5:55 PM
Since classes can use coroutines and
functions, you can have a tuned approach on how each field is resolved and how you cache the response server side. We don’t take an opinion on how to save repeated requests if you want to use data loader or some custom cache solution. There is an example of how to use the existing
java library though here:


05/14/2020, 5:58 PM
gotcha, that makes sense. i’m pretty new to kotlin and coroutines so i haven’t tried making my own cache … if you have some sample code, i’d appreciate a jump start!
i’ve got dataloader working now, but i can foresee running into problems intermingling coroutines and completeable futures
(thanks again for the quick response!)

Krystian Rybarczyk

05/14/2020, 6:08 PM
coroutines have actually pretty good interop with completable futures AFAIK. There are extension functions which let you easily convert between the two. I have been using them quite happily


05/14/2020, 6:20 PM
ah yeah, i’ve seen the
extension function … very cool
the problems seem to arise when using dataloader within a coroutine … graphql-java has special hooks for dataloader that aren’t triggered when it encounters a coroutine first
so after playing around with this for a bit, i have two questions:
1. where’s a good place to cache data for reuse between resolvers in a request? the graphql context?
2. is there a good pattern for batching? dataloader coalesces multiple calls to
to allow making one network or database request with multiple ids
it looks like the java dataloader has special hooks using graphql-java’s instrumentation … i’m not sure how else i can batch calls without it