Anyone else actually quite alarmed at Ktor Roadmap...

# ktor

[darkmoon_uk]

Anyone else actually quite alarmed at Ktor Roadmap's goal of '_supporting DI frameworks_'.
This should not be the concern of a Networking library; which is how Ktor has always been positioned.
I do not want to see Ktor become an Application Framework! The line has always stopped at the 'routing' layer, and that's been great.
Let us have our own opinions after that.
Any support had better be completely decoupled, both in code and by module/dependency or I will be seriously upset at the direction TBH.

[Oliver.O]

I’d not be too alarmed. So far they have demonstrated a good track record in designing composable and unopinionated APIs. I don’t expect that to change. My guess is that supporting DI is more like adapting to popular demand rather than being a functional necessity. For me, I expect my DI/magic ignorance to remain alive and kicking. 🙂

[simon.vergauwen]

I am quite concerned, not just about DI. I have already shared my concerns extensively on Twitter but let me share them here again, since I saw the request on Twitter to provide feedback. (Sorry for long text).

First of all I want say that I have been a huge fan, and supporter of Ktor and want to thank everyone involved for their amazing work!

There are 2 things I was rather concerned about:

DI:
For several reasons. It mentions Koin as the driving implementation, and that concerns me because the Koin & Ktor integration has existed for a long time (6+ years ?). So what is changing? Is the integration being moved to the official Ktor repository? If so, why? Should other libraries also get the same treatment of being promoted to the Ktor repository and thus benefiting from official promotion, and help maintaining and publishing the library? I think there is a huge risk for discrimination here, which is totally unrelated to the fact that I am not a fan of DI/magic frameworks. In fact, running away from them is why I cam to Ktor in the first place.

That being said, I am not against DI if it's opt-in, and thus not build into core whilst my other concern is also addressed. I'm not sure how that could work, but if the political / discrimination issue is tackled than I think my concern here is addressed.

Ktor is so flexible that any 3rd party can easily build support for Ktor whilst it feels 1st party. So I don't see a strong need for this, an alternative could be allowing OSS projects to freely share -and showcase their Ktor integrations.

Managed Transactions:
There is some assumption on my part based on the description of the feature, and the existing functionality out there in the current ecosystem (Spring/Hibernate @Transactional).

This is not an integration but a full blown feature, I have no idea how it'll be intended to be implemented since at some level it also requires integration with some database (and KMP?).

I am against this feature because, especially when it occurs implicitly I find it a dangerous practice.

Overall:
Overall, even if both features are opt-in I feel a bit sad that seemingly such a big portion of the roadmap will be spend on features that I think don't align with the original Ktor userbase. If the goal is to attract people from Spring, I personally think it's a mistake. Kotlin is differentiating from Java, and will continue to do more so in the future. I think Ktor should continue in the direction it's going, and continue to differentiate from the Java/Spring ecosystem not move closer to it.

I have many ideas of features that I think can be improved, and/or deserve some more love. Here is also an example of how I deal with what is otherwise known as managed transactions, but in a typed way using Kotlin language features. https://x.com/vergauwen_simon/status/1767609080200253921?s=20

I'd be happy to discuss this further with anyone that is interested ☺️ Just wanted to share my thoughts, and concerns. Which are not all technical, but come from my experience being in the Kotlin community for 8 years, and being an OSS developer for 7 years.

[darkmoon_uk]

Yes; the roadmap also mentions working on those things because '_many users have asked for explicit recommendations on how to integrate frameworks like Koin_'. To me that doesn't justify spending Ktor Devs time on writing actual support or integrations into the library itself. Again, it's not something I expect Ktor as a (very, very good) Neworking library to have an opinion about.

[Oliver.O]

Thanks for sharing your concerns on this (and since we're in a thread, longer texts are welcome, I guess).

Regarding DI, I'm reading the roadmap's phrases "_frameworks like Koin_" followed by "_add support for DI_" as not necessarily implying that Koin will be the primary or only DI framework supported. Managed transactions are announced to be supported as a plugin, so entirely optional. Then factor in the intention of offering a plugin registry. Wouldn't that provide a visibility and convenience boost so that "any 3rd party can easily build support for Ktor whilst it feels 1st party"? I also trust them to live by their values such as "_We aim to keep the framework lightweight, flexible, and transparent_" and supporting a viable OSS market ("_remove impediments to community contributions_").

Maybe the Ktor team could provide additional clarification, but that's what I'm extracting from the announcement.

[e5l]

Hey folks! Thank you for raising the question!

The short note before long details: all the features we're planning are not going to be integrated (or coupled) into the framework, and all will be optional to use :)

Let me explain some details about the DI point in the roadmap.

The overall purpose of Ktor is to provide simple and extensible solutions for writing web applications and services. We're trying to keep an eye on the technical aspect and how people are actually using Ktor.

We see many people trying DI in the application with Ktor. And we're thrilled to have great solutions for that in the community :) However, we also see many people struggle with configuring and using the DI. There is also a technical gap between the existing solutions and Spring Boot, and we see how we can help to fix it with a little effort.

As a result, we will have plugins on start.ktor.io for the most popular DI frameworks, which will generate the project with the configured DI framework and an example of its usage. It also will include the testing aspect. We will also provide some opt-in tools inside the Ktor Gradle plugin for them to drop manual repository configuration.

The design is still in the early phase, and we're happy to have discussion and feedback.

[e5l]

As mentioned, we're going to open source Ktor plugin registry for start.ktor.io and make it open to contribution next week. It will include integration testing for third party plugins as well.

[e5l]

Sorry for the long post. If you have any questions or want to discuss the roadmap - feel free to ask 🙂 Or we can organize a short meet so we can have the detailed discussion about plans and suggestions

[dave08]

I'm a bit unclear of how this will work... in the new post about DI, it just says you have to write install(Koin) , and it'll know how to inject all the dependencies... What does the user have to do to use those dependencies in Routes? Will there be controller classes that can be injected? We currently use KotlinInject and have InternalEndpoints and ExternalEndpoints interfaces that have a fun Route.setup() function for all our "modules" containing routes for different purposes (that are injected by the DI). Then we use @IntoSet from kotlin inject to make a set of each kind and loop over them in the main Routing under internal/external `localPort`s (with authentication for external routes). Will this new feature simplify anything here, or is it really just for those that aren't managing with DIs?

[e5l]

Hey @dave08, thanks for the question. We don't plan to introduce controllers, it should be a DI specific feature.

We're looking into simplifying of use sites, but no design at this point.

[dave08]

When the design gets ahead, it would be nice to have an idea of how this would look concretely before implementing it, that way you might get feedback from user's pain-points... I think this is starting to look like a solution for only a part of Ktor's users, but then, I'm not sure how such a thing can be more than that... at least it's clear it's not going the controllers direction, thanks! I'm not sold in on Controllers, I'm just finding it the easiest way to inject `UseCase`s into...