KTOR-7820 Dependency injection design

[bjhham]

This is a proposal to resolve:

https://youtrack.jetbrains.com/issue/KTOR-6621/Make-Dependency-Injection-Usage-Simple

The goal here is to provide an easy way to introduce dependency injection for new users, especially those who are accustom to the ease of frameworks like Spring. I tried to address any drawbacks found in other solutions and keep to the Ktor philosophy as much as possible.

[osipxd]

Rendered preview

[osipxd]

Possible alternative syntax:

fun Application.configure() {
    val repository by dependencies.resolve<Repository<User>>()
}

if we want to have a common entry point for both declaration and resolution APIs.

[bjhham]

I like the symmetry, though it's a tad verbose.

[osipxd]

Another alternative:

val repository: Repository<User> by dependencies

But it requires tweaking to support named instances.

[bjhham]

I'm thinking now...

// basic use case
val repository: Repository<User> by dependencies

// with named instance
val repository: Repository<User> by dependencies.named("users")

// or without property delegate
val repository: Repository<User> = dependencies.resolve()
val repository: Repository<User> = dependencies.resolve("users")

[arnaudgiuliani]

With such an approach on Koin, we propose also to use type qualifier, to use class or enum instead of strings

[osipxd]

This introduces temporal coupling between the two phases of declaration and
resolution

So we can avoid this only by making resolve suspending, right? Could you add some context why we decided not to do this?

[bjhham]

My thoughts are that during declaration they'll suspend like this, but at a certain point we have to decide that declarations are done so that we know when to fail.

[osipxd]

In Koin you can also pass a constructor instead of lambda. All parameters will be retrieved using get():

factoryOf(::Repository)

This solution is a compromise between manual and reflective instantiation.

[bjhham]

Oh, I like that!

[arnaudgiuliani]

If I can add some clarification here: no reflection, it's a (dirty) trick to match the signature and fill in the needed dependencies.

[osipxd]

If I can add some clarification here: no reflection, it's a (dirty) trick to match the signature and fill in the needed dependencies.

Thank you for the clarification! Yes, I called it "a compromise" because it is as fast as manual instantiation but lacks some features of reflective instantiation. Though, I can name only one missing feature - named instances aren’t supported.

[arnaudgiuliani]

yes, this is a point where I would need a compiler plugin or something here

[bjhham]

Yeah, I don't think it's possible to get around the use of annotations + reflection for named instances when injecting constructors.

[arnaudgiuliani]

Yeah, this is a question that I try to tackle for Koin too. Or perhaps a special type marker? But then your constructor property is linked to something of the framework 🤔

[arnaudgiuliani]

In spring framework, previous to annotations, we had to specify it manually

[JakeWharton]

Hello!

The "current solution" examples provided for Koin and Kodein, and the proposed Ktor APIs are not dependency injection. They are service location. A single service locator instance is supplied from which dependencies can be imperatively pulled.

Let's look at the Wikipedia article you start by citing (https://en.wikipedia.org/wiki/Dependency_injection):

dependency injection is a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally

and

Instead, the receiving "client" (object or function) is provided with its dependencies by external code (an "injector"), which it is not aware of

Neither of the examples nor the proposed API receive the objects or functions they require directly. And neither example nor the Ktor API is unaware of the source from where it resolves its dependencies.

Instead, each receives a single, framework-specific instance registry from which it pulls the dependencies that it requires as implementation detail.

Let's contrast that with the service locator pattern from Wikipedia (https://en.wikipedia.org/wiki/Service_locator_pattern):

This pattern uses a central registry known as the "service locator", which on request returns the information necessary to perform a certain task.

That description precisely matches what is going on in samples and the proposed API.

There is nothing inherently wrong with service location vs. dependency injection–it's simply a different pattern. I would strongly suggest renaming this proposal and its proposed APIs to be named after the correct pattern that it is modeling.

[bjhham]

Hi @JakeWharton, this design places more focus on the manual declaration of dependencies as with a service locator, but it's intended to be used with automatic instantiation through reflection as well (see section). From what I understand, this automatic injection of types is the only meaningful distinction.

I'll make some updates to expand a bit more on this concept - the intention of the design is to separate dependency declaration and resolution, so that resolving types from your modules can be handled through any means - automatic, external, or otherwise.

[JakeWharton]

I saw that. However, that section contains this sentence:

For the initial prototype of dependency injection in Ktor, we can forgo this automatic instantiation, but it would be useful to discuss the approach here for future reference.

Additionally, it's extremely hand-wavy on behavior, and is not a concrete part of this proposal.

This proposal is for a service locator with an imperative API. Perhaps a future proposal can layer dependency injection on top of that service locator. Almost all of the popular dependency injectors are built on top of a service locator, so this is with precedent.

By updating this proposal to accurately reflect what is being designed today we can properly set expectations and use the correct definitions for the provided behavior and API. The reflection-based can then be updated to refer to itself as dependency injection with the Wikipedia link and so on.

[bjhham]

Fair point. I'll update the document with some greater clarification in this regard.

[e5l]

What would be nice to have is an API for integrations with other DIs (so the repository can be reused).

[e5l]

Should we try registring injectables (like factories) in the configuration file?

[e5l]

Could you tell me what you think about supporting parameters injection for the modules declared in the config file?

dependencies:
    mongo: DatabaseKt.mongoProduction

modules:
   - ModuleKt.module
   

fun Application.module(mongo: DataSource) {
    // ...
}

[e5l]

We also can allow registries from DI framework to contribute to shared Ktor registry, so they can benefit from the syntax we have

[e5l]

Hey @bjhham, thanks for the proposal. I've left some comments, please take a look.

btw I think @JakeWharton made a good point about naming. Let's adjust names and mention the difference in the description explicitly!