Koin + Ktor DI 3.2 Integration

[lidonis]

Ktor DI Bridge Implementation

• Added KoinDependencyMapExtension implementing Ktor 3.2's DependencyMapExtension interface
• Registered via SPI in META-INF/services/io.ktor.server.plugins.di.DependencyMapExtension

Koin can resolve Ktor DI dependencies via KtorDIExtension resolution extension.

• There is a potential problem with runBlocking usage

When dependency is not found, each library is delegating to the other in an infinite loop

Fixed a problem in CoreResolver that was not resolving extensions

Created a sample application to show usage.

[arnaudgiuliani]

even 3.2.2

[arnaudgiuliani]

ok

[arnaudgiuliani]

Let me check if we have a lookup check here, else we are directly resolving the key

[arnaudgiuliani]

@osipxd we can't use getDeferred here, as we don't have reified type info from this point. we only have KClass.
Not sure runBlocking is the good way. Else we can go with typeOf() or something ?

[bjhham]

The key construction using the class reference looks right since the reified type's not available.

You can use application.dependencies.getBlocking(key) here to let Ktor handle the blocking part.

In the case of property delegates, we also have a step to indicate that the key should be checked during startup validation, which might be applicable elsewhere:

public inline operator fun <reified T> provideDelegate(
    thisRef: Any?,
    prop: KProperty<*>
): ReadOnlyProperty<Any?, T> {
    val key = DependencyKey<T>()
        .also(::require)
    return ReadOnlyProperty { _, _ ->
        getBlocking(key)
    }
}

[arnaudgiuliani]

Ok, interesting. Thanks

[arnaudgiuliani]

@bjhham one question: if Ktor DI is falling back on Koin and Koin falling back on Ktor DI, we might go with looping when none of the DIs have a given definition

[bjhham]

Will need to either reference the unextended counterparts as the fallbacks, or introduce a flag in the qualifier to break the loop, or just allow the bridge to call in one direction.

[bjhham]

👍

[bjhham]

The key construction using the class reference looks right since the reified type's not available.

You can use application.dependencies.getBlocking(key) here to let Ktor handle the blocking part.

In the case of property delegates, we also have a step to indicate that the key should be checked during startup validation, which might be applicable elsewhere:

public inline operator fun <reified T> provideDelegate(
    thisRef: Any?,
    prop: KProperty<*>
): ReadOnlyProperty<Any?, T> {
    val key = DependencyKey<T>()
        .also(::require)
    return ReadOnlyProperty { _, _ ->
        getBlocking(key)
    }
}

[lidonis]

Thanks @bjhham for the getBlocking suggestion!
That's definitely cleaner than wrapping with runBlocking.
However, there's a challenge: getBlocking is unavailable on WASM/JS targets, which would break multiplatform compatibility.

Since we need this to work across all Kotlin targets, we might need to stick with the current approach or implement a platform-specific solution:

expect fun <T> getDependencyBlocking(dependencies: DependencyMap, key: DependencyKey<T>): T

// JVM/Native implementation
actual fun <T> getDependencyBlocking(dependencies: DependencyMap, key: DependencyKey<T>): T = 
    dependencies.getBlocking(key)

// JS/WASM implementation  
actual fun <T> getDependencyBlocking(dependencies: DependencyMap, key: DependencyKey<T>): T = 
    runBlocking { dependencies.get(key) }

This way we get the benefits of getBlocking on platforms that support it, while maintaining compatibility with WASM/JS targets.

Thoughts on this approach?

[bjhham]

Hey @lidonis you can use getBlocking on other platforms, but it can only be used with deferred processing, so lazy retrieval and access after the server is started. It is this way due to the lack of runBlocking available in JS/WASM targets.

[arnaudgiuliani]

I propose to make the options to bridge explicit for now, to avoid any unwanted behavior. Also need time to get some feedback.

We may need to ask for explicit behavior for now, and let people setup things a bit like that:

[arnaudgiuliani]

@bjhham the dependencies.getBlocking<Any?>(key) is not working, even if we pass the right class to the key:

dependency key is forged with targeted class:

Trying to ask Ktor DI for a given class, already declared in dependencies section:

[arnaudgiuliani]

I follow it in #2294