Does graphql-kotlin support dependency injection?

[dave08]

It seems from the docs that you need to keep some global vals for all the repositories, making a bit difficult to set up unit test fakes for them...

The only mention of this kind of thing is here: https://opensource.expediagroup.com/graphql-kotlin/docs/schema-generator/schema-generator-getting-started#dynamic-toplevelobject, but there's no mention for data loaders and the entities that aren't top level...

[dariuszkuc]

Hello 👋
Core schema generation logic only concern is with GraphQL and DI is outside of its scope of responsibilities. DI is higher level concept that is handled by your specific server implementation.

Our graphql-kotlin-spring-server library is a SpringBoot autoconfiguration library to easily run reactive GraphQL servers. Since it is SpringBoot based, it does support Spring DI mechanism (see docs).

If you are looking at servers outside of Spring, then you can use whatever mechanism they support, e.g. see Ktor + Koin example.

Side note: data loaders should always be accessed through DataFetchingEnvironment (as they are created per execution) and generally should not be injected directly to your classes

[dave08]

This example shows that you DO handle a sort of DI since DataFetchingEnvironment is a primitive type of DI... why not have something a bit better, like having some kind of resolver interface that needs to be implemented to be able to resolve dependencies from a proper DI framework, and then plug them straight into the entity classes:

[https://github.com/darkxanter/graphql-kotlin-ktor/blob/4b2b414af411044701d9a1eb06b[…]/example/src/main/kotlin/example/feature/articles/ArticleDto.kt](https://github.com/darkxanter/graphql-kotlin-
ktor/blob/4b2b414af411044701d9a1eb06ba383fd62716e1/example/src/main/kotlin/example/feature/articles/ArticleDto.kt)

@GraphQLName("Article")
@GraphQLDescription("Article")
data class ArticleDto(
    val id: Long,
    val created: OffsetDateTime,
    val authorId: Long,
    val title: String,
    val content: String,
) {
    fun author(dfe: DataFetchingEnvironment): CompletableFuture<User> {
        return dfe.getValueFromDataLoader(UserDataLoader::class, authorId)
    }
}
// The dfe way is messier than:
@GraphQLName("Article")
@GraphQLDescription("Article")
data class ArticleDto(
    val id: Long,
    val created: OffsetDateTime,
    val authorId: Long,
    val title: String,
    val content: String,
) {
    fun author(authorRepo: AuthorRepository): CompletableFuture<User> {
        return authorRepo.getAuthor(id)
    }
}
// Also, it requires making a data loader for each thing...

[samuelAndalon]

The graphql-kotlin-ktor plugin is not part of the ExpediaGroup Open Source organization.
regarding the access to Data Loaders, IMHO, we should stick to the way how graphql-java designed the access to then trough the graphql-java DataFetchingEnvironment.

As @dariuszkuc mentioned, data loaders are created by execution, or by request, (depending how you configured it), so accessing them through the DataFetchingEnvironment guarantees that.