MappedBatchLoaders in 6.x? (replacing DataLoaderFactory.newMappedDataLoader from 5.x)

[terminalnode]

In our SpringBoot application running 5.x of graphql-kotlin-spring-server (and related libraries) we make heavy use of mapped data loaders using this pattern:

class MyDataLoader() : KotlinDataLoader<K, V> {
  override val dataLoaderName = "MyDataLoader"
  override fun getDataLoader() : DataLoader<K, V> =
    DataLoaderFactory.newMappedDataLoader(/* ... */)
}

In 6.x getDataLoader has been replaced with getBatchLoader which is supposed to return a BatchLoader<K, V>. There is MappedBatchLoader<K, V>, but that's not a BatchLoader.

How would I register mapped batch loaders in 6.x?

[dariuszkuc]

Don't remember the exact reason for change but it looks like it was a miss on our side.
@samuelAndalon - can we change it back to DataLoader? DataLoaderFactory has quite a few different methods for building a DataLoader that are not captured by just using BatchLoader interface.

[terminalnode]

I found this when looking for answers to my question, might help. Some discussion about it there.

[samuelAndalon]

Hello, there are a couple of reasons why we changed the KotlinDataLoader to allow passing the BatchLoader fn instead of the DataLoader instance:

1. We are working in a better Instrumentation to dispatch DataLoaderRegistry in a more efficient way, so for that we had to decorate the DataLoader CacheMap before instantiating the DataLoader.
2. the issue that @terminalnode highlighted.

about point 1 a PR in graphql-java-dataloader was merged to natively support what we where doing to the CacheMap

so we can theorically go back to previous KotlinDataLoader implementation.

ill work on that.

BTW @terminalnode if you are relying on DataLoaders i would like to encourage you to take a look at
https://opensource.expediagroup.com/graphql-kotlin/docs/server/data-loader/data-loader-instrumentation

we added support for usage of dataloaders by multiple graphql operations (a batched request) and dispatch the registry using an async execution exhaustion strategy -- this may help you to optimize your resolvers/data fetchers

[terminalnode]

so we can theorically go back to previous KotlinDataLoader implementation.
ill work on that.

To be clear, can we then expect that this behaviour will return to how it was before (or something similar to it)?

BTW @terminalnode if you are relying on DataLoaders i would like to encourage you to take a look at
https://opensource.expediagroup.com/graphql-kotlin/docs/server/data-loader/data-loader-instrumentation

I did run into that when looking into this issue. It looks very neat and we're probably going to look into this once everything is up and running with the updated versions. Though to be clear, as I understand it this is a way to optimize usage of data loaders, correct? Not an alternative to the KotlinDataLoader / DataLoaderFactory.newMappedDataLoader issue?

[dariuszkuc]

BTW @terminalnode if you are relying on DataLoaders i would like to encourage you to take a look at
https://opensource.expediagroup.com/graphql-kotlin/docs/server/data-loader/data-loader-instrumentation

I did run into that when looking into this issue. It looks very neat and we're probably going to look into this once everything is up and running with the updated versions. Though to be clear, as I understand it this is a way to optimize usage of data loaders, correct? Not an alternative to the KotlinDataLoader / DataLoaderFactory.newMappedDataLoader issue?

Yes. New instrumentations help with optimizing usage of dataloaders across batch requests.