Ktor 2024 Roadmap DI Update
Since the Ktor Roadmap for 2024 was published there have been a lot of questions regarding Dependency Injection (DI). Specifically how Ktor will be changed to support DI, and to integrate existing DI frameworks. This work is still in its early stages, but we would like to clarify our intentions and invite feedback.
First and foremost, we would stress that:
- There will never be any requirement to use a DI framework with Ktor.
- Ktor itself will never include a DI framework as part of its design.
The proposed feature is solely for users who wish to combine DI with their Ktor services. We want to help existing DI frameworks integrate with Ktor as seamlessly as possible.
How the proposed Dependency Injection feature will work
Let’s consider how we could use Koin within a Ktor route. Imagine the unfortunate scenario where we require seven separate services in order to purchase the contents of the customer’s shopping cart:
fun Application.root() {
install(Koin) {
modules(module {
single { PricingRules() }
single { DiscountRules() }
single { StockCheckRepository() }
single { DeliveryRoutePlanner() }
single { PaymentGateway() }
single { CreditRatingChecker() }
single { PastPurchasesRecord() }
})
}
...
}
The DI framework will create and inject the dependencies for us. But because Ktor has no knowledge of Koin we have to specify the dependencies manually. Also the injection process is complex, requiring Delegated Properties and Type Parameters.
Our proposal is to replace the above with something like this:
fun Application.root() {
install(Koin)
...
}
This will be achieved as follows:
- You will be able to select which DI framework (if any) you wish to use in the Ktor Project Generator. We hope to support all popular DI frameworks.
- The presence of a DI framework will be noted by the Ktor Gradle plugin. It will automatically find all the components managed by that framework.
- The plugin will add new methods to these types, which will enable you to inject them in the simplest possible way.
Our goal is to radically simplify how DI is used within Ktor, without adding any extra complexity. The code generated by the Ktor Gradle plugin will be fully debuggable, and the pipeline architecture will not be modified at all. You will be able to use this new approach in both services and tests.
Hopefully, fans of DI will find this a great improvement, but like DI itself, this will be a completely optional feature. You will still be able to use the DI framework’s native syntax if it suits you better.
As always we remain committed to Ktor’s founding principles. Every feature we add is aligned with the vision of a no-magic, lightweight solution that is minimalist, simple, flexible, and fast. To help shape the future of Ktor, please join the discussion on the Ktor channel of Kotlinlang Slack (request an invite to Slack).
Subscribe to Kotlin Blog updates
