A modern programming language that makes developers happier.

kotlinlang

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

Since classes can use coroutines and `suspend` 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 `data-loader` java library though here:

<https://github.com/ExpediaGroup/graphql-kotlin/pull/396>

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

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

ah yeah, i’ve seen the `.await` 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 `dataloader.load(id)` 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