I've been looking to remove some of our old custom...

# graphql-kotlin

[Joe]

I've been looking to remove some of our old custom glue code and using more of the graphql-kotlin-server provided infrastructure. ran into some questions about KotlinDataLoaderRegistryFactory and `GraphQLContext`:
• Our dataloaders sometimes need access to things in the GraphQLContext, which we've dealt with by setting the GraphQLContext as the BatchLoaderContextProvider , and then accessing within a dataloader by doing environment.getContext<GraphQLContext>()
• It seems like in order to do the same thing, we'd need to make the GraphQLContext accessible to each KotlinDataLoader that we construct and create the BatchLoaderContextProvider option when using DataLoaderFactory.newDataLoader()
• That's all doable, but seems a little awkward (leads us down a FactoryFactory / FactoryProvider type route which always seems a little too JEE-ish) -- would it make sense to have a way for the RegistryFactory to handle DataloaderOptions directly instead ? or is there another way to expose the GraphQLContext to the `KotlinDataLoader`s that I'm missing?

[Dariusz Kuc]

@Samuel Vazquez

[Samuel Vazquez]

👋 , we just merged
https://github.com/ExpediaGroup/graphql-kotlin/pull/1490

couple of extension functions that will allow you to access to the GraphQLContext from the BatchLoaderContext , the way we do it is slightly different and recommend pass the dataFetchingEnvironment as a second argument of your DataLoader.load fn

foDataLoader.load(key, dataFetchingEnviroment)

then in your batch loader function you can just

DataLoaderFactory.newDataLoader { keys, environment: BatchLoaderEnvironment ->
  val graphQLContext = environment.getGraphQLContext() 
}

[Samuel Vazquez]

this is possible because the BatchLoaderEnvironment contains a context yes, but also contains a context by key (that would be the dataFetchingEnvironment)

https://github.com/graphql-java/java-dataloader/blob/master/src/main/java/org/dataloader/BatchLoaderEnvironment.java#L48

[Samuel Vazquez]

the extension functions we added are just a short hand to do

(batchLoaderEnvironment.keyContextsList.firstOrNull() as? DataFetchingEnvironment)?.graphQLContext

[Samuel Vazquez]

you can check this test for a full example
https://github.com/ExpediaGroup/graphql-kotlin/blob/master/executions/graphql-kotl[…]trumentation/extensions/BatchLoaderEnvironmentExtensionsTest.kt

[Samuel Vazquez]

GraphQLContext is build in runtime by ExecutionInput (graphql request) so it makes sense to provide it as part of the .load() fn

[Joe]

ah interesting, so you end up with the same keyContext object for every key that gets dataloaded, and just assume the first one? Thanks for that idea, will play with which approach makes more sense for us.

[Dariusz Kuc]

@Joe if you got ideas how to make dataloader integrations easier feel free to open up issue/pr with details

[Joe]

thanks I'll see what I come up with. it does seem to me that having the batch loader "overall" context always be the GraphQLContext makes sense, but maybe there are cases where it doesn't? but my ideas will probably be around making that easy to do if not default

[Samuel Vazquez]

ah interesting, so you end up with the same keyContext object for every key that gets dataloaded, and just assume the first one? Thanks for that idea, will play with which approach makes more sense for us.

yes, at the end is just a reference to an object so should not be expensive, plus it opens the door for the capability to access to a the DataFetchingEnvironment by loaded key