Roadmap

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:

1. There will never be any requirement to use a DI framework with Ktor.
2. 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:

1. 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.
2. 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. 
3. 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).

As in 2023 and 2022, we have been working on a roadmap for our development of Ktor for the year ahead. In the interests of transparency and accountability, we would like to share our plans with you here.

Our ongoing plan

Our ongoing plans and goals for Ktor remain consistent with previous years. We aim to keep the framework lightweight, flexible, and transparent, so our users can easily create powerful and maintainable services and clients.

With each new release, we try to improve the quality and performance of the features we provide, while simultaneously expanding our ecosystem of Ktor plugins. This involves introducing new plugins to simplify existing use cases (like transaction handling) and adding support for new ones (such as Observability and gRPC).

Along with improving the core product, we want to make the development experience easier for our users. We aim to make the plugin ecosystem easier to work with and to remove impediments to community contributions. We are also working to improve the range, quality, and variety of the documentation we provide.

Lastly, we want to take advantage of the stabilization of Kotlin Multiplatform (KMP) and the growing ecosystem of multiplatform libraries. Our goal is to make the benefits of KMP available to Ktor developers and empower them to create multiplatform applications.

New features

We intend to deliver the following new functionality in 2024:

OpenTelemetry plugins

We plan to introduce OpenTelemetry plugins for Ktor Client and Server, which will enable you to generate telemetry data (metrics, logs, and traces) and advertise it for collection.

gRPC based services

We have already been working to add gPRC support. In 2024, we will integrate gRPC into both Ktor Client and Server via an idiomatic Kotlin implementation. This will make creating and consuming gRPC-based services as natural and familiar as HTTP and REST.

Migration to Kotlinx-io in Ktor 3.0.0

Kotlinx-io is a multiplatform library that provides abstractions for data sources and destinations. Before Ktor 3.0.0 becomes final, we intend to replace the existing bespoke networking types with those provided by Kotlinx-io. This will make it much easier for creators of multiplatform libraries to support Ktor Client and Server. With this update, the existing IO functionality is now deprecated and will eventually be removed.

Add support for managed transactions

At present, Ktor services require manual management of database transactions, which is appropriate in complex scenarios. However, in many cases, it is preferable to start a transaction at the beginning of the request and commit it at the end, provided there are no errors.

In 2024, we will introduce an official plugin that implements this behavior. This will simplify database access while providing support for recovering from SQL and application-specific exceptions.

Simplified dependency injection

Until now, we have been agnostic on dependency injection (DI) libraries, preferring to allow users to integrate their preferred products as they see fit. However, many users have asked for explicit recommendations on how to integrate frameworks like Koin into Ktor-based services.

In response to this, we will officially add support for DI into Ktor Server in 2024, and publish guidelines on how best to integrate existing DI libraries.

Making Ktor development better

Along with adding new features to Ktor, we will be making changes that simplify the development process and expand your potential options:

Improved documentation

Based on the feedback we received over the past year, our focus for 2024 is on enhancing current content quality and expanding support with new materials. Our primary goal is to make the learning journey more flexible and straightforward – a goal we aim to achieve over several iterations:

• Extending, improving, and streamlining the tutorials in the Getting Started sections of the Ktor Server and Ktor Client documentation.
• Addressing cloud deployment and configuration topics.
• Introducing a comprehensive guide on full-stack development with Kotlin Multiplatform.
• Increasing the scope of API coverage in our documentation.

We are also planning structural changes. Tutorials will seamlessly complement each other, interlinking topics more efficiently, and Server and Client content will be reorganized to ensure clearer distinctions.

All of these additions will take advantage of a modernized look and feel, plus integration with the documentation for other JetBrains frameworks and libraries.

A plugin registry

Currently, the online project generator only offers plugins created by the Ktor team. While users can create and integrate their own plugins into services, there is no way to register them for other teams to use. This impedes the growth of the Ktor community.

To fix this, we will introduce a mechanism for accepting third-party Ktor plugins. 

This will consist of:

• A new, simplified format for creating Ktor plugins. This format will enable you to include all of the information needed to register and display the plugin within the project generator.
• A new version of the project generator, with support for registering external plugins.
• A procedure for submitting a pull request to the Ktor team in order to begin the process of evaluating and registering a third-party plugin. 

A command line tool

At present, we recommend creating new Ktor-based projects using either the online project generator or the wizard in IntelliJ IDEA Ultimate. While these two methods cover most scenarios, there is demand for a command line-based alternative. This would allow users to create and modify projects within the terminal or shell.

In response to this demand, we will publish a CLI Tool for Ktor in 2024.

Conclusions

We hope these plans sound exciting and address any outstanding issues you may have with the framework. Thanks to everyone who helps keep the Ktor community flourishing and expanding, whether through contributions, feedback, patronage, or advocacy. If you would like to comment on these plans or suggest additional features, we encourage you to join the discussion on the Ktor channel of Kotlinlang Slack (request an invite to Slack).