I see the DI docs have been added: <https://ktor.i...

# ktor

[Arjan van Wieringen]

I see the DI docs have been added: https://ktor.io/docs/server-dependency-injection.html. Some questions though:
• dependencies block is not clear that is is part of Application scope. We can't have Call-scoped dependencies?
• Are the dependencies singletons (I assume so, but it is not made explicit)? Can they be made not singletons? Is there support for 'multitons'?

[simon.vergauwen]

• Yes, there is currently no specific support for scoping. If this is important to you please file an issue with your motivation.
• There is support for multitons. Let me double check the API docs. It's all singleton.

[Arjan van Wieringen]

Thanks!

[Bogdan Vladoiu Lbs]

Arjan what you call application scope or main scope is "just another scope" in the next application. The main comonent Application in yout first application, is "just another component" in the next application. Singleton needs to crawl into a museum and die. Think in scoped components!

[Bogdan Vladoiu Lbs]

if ktor DI dont deliver this. it was nice meeting you, im going back to Vertx im not going to make server components with DI

[simon.vergauwen]

It would be awesome if you could create a ticket providing more details @Bogdan Vladoiu Lbs.

[Bogdan Vladoiu Lbs]

not sure i can right now. kotlin has a miriad of coroutine libraries all predicated on some concurency model. async, suspend, blocking. the only way of marrying them to one another in the same application is CoroutineScopes. i hope someone gets it

[Bogdan Vladoiu Lbs]

its not a multiplatform thing anymore. the first backend adopter of your library may have a backend predicated on suspend. the second one might have a backend predicated on blocking/threads. the third one might be async. its the same in clients, platform doesnt matter anymore. the clients are different on the same platform

[simon.vergauwen]

That's not my experience at all 🤔 Also I'm not entirely sure how that relates to Ktor or DI.

If you have time to share more details, feel free to hit me up by DM or on the Ktor YouTrack or Github issue tracker. It would be much appreciated.

[Bogdan Vladoiu Lbs]

i'm 90% sure well be able to use CoroutineScope into a dependency outside of the di framework. hew! To put it simply when i am handed over something that works async and something with suspend top level api and something that blocks. i just need to be able to scope each component with CoroutineScope to make them work together. in the same app. there is nothing more to it than that

[simon.vergauwen]

Okay, I see. Ktor already allows that through Application which is a CoroutineScope which the same lifecycle as the server.

In Spring you can pretty much do the same by defining a custom Scope, https://gist.github.com/nomisRev/809ed20bbed7c6170815e985dee1ba71#file-springscope-kt.

[Bogdan Vladoiu Lbs]

aha, thank you! like for exammple. i make a simple socket cli app. when i move it into ktor i just want to be able to throw a coroutine scope over it or in it to make it work with the server.

[Bogdan Vladoiu Lbs]

i'm going to be able to do it. thank you!

[simon.vergauwen]

This might interest you, it's dependency-less although it lives in Arrow-kt now. https://github.com/arrow-kt/suspendapp?tab=readme-ov-file

It's a version of runBlocking that turns hooks into termination signals, and respects structured concurrency on termination. Also works on NodeJS, and native desktop targets.

[Bogdan Vladoiu Lbs]

omg this would have saved me from losing it a while ago with kotlinjs on node. 🙂 much appreciated!

[Pablichjenkov]

IMO making a DI abstract layer to host any other DI framework is not great.
I think with this purpose it is better to release independent artifacts that tie ktor to a specific DI framework. Let's say ktor-koin, ktor-dagger, ktor-kodeIn and such. Perhaps harder to maintain but easier for the consumer developer

[Arjan van Wieringen]

But this isnt an abstract layer to host other DI frameworks afaik

[Pablichjenkov]

It is not abstract that's right sorry for the confusion but it is still an intermediate layer.

[Arjan van Wieringen]

No? It is a standalone DI implementation.

[Bogdan Vladoiu Lbs]

looks standalone:
implementation("io.ktorktor server di$ktor_version")

[Pablichjenkov]

I haven't checked that, I just talk by the release notes.
From the release notes it seemed to me it was a general way to apply dependency injection. Where you can access the graph or subgraphs and inject specific classes. But maybe is more than that, I gotta check, thanks for the link