If we're developing a big scale application with K...

# ktor

[Shreyas Patil]

If we're developing a big scale application with Ktor in which there might be many modules. Which DI framework is recommended to use? I saw Kodein, Koin, etc. But they uses reflection I guess which might affect performance? I can use Dagger but it not looks good solution in Ktor since everything here is in functions in Ktor. Any suggestion for choosing right DI Framework? My question might be wrong because I'm not from backend development. I've used DI in Android a lot so just want to see how it can be used here

[John O'Reilly]

one advantage at least of using Koin or Kodein is that they work in Kotlin Multiplatform code

[Shreyas Patil]

Yeah! But I want some suggestions in the context of performance on server

[Shreyas Patil]

Because application needs quick response on front-end after performing some database operations on server.

[aleksey.tomin]

As I know Kodein doesn't use reflection.

[Shreyas Patil]

Read this 👇

[Shreyas Patil]

Ref link: https://docs.kodein.org/kodein-di/7.1/platform-and-genericity.html

[christophsturm]

DI server performance does not really matter because you wire up the components at startup.

[Shreyas Patil]

Okay, thanks!

[Joost Klitsie]

From hobby project perspective, I did not see any issues with Kodein and I actually liked the fact that I can use the same DI framework for the backend as well as my frontend. It made me very productive (which is good, as I don't have so much time for hobby projects). I do think that Christoph's comment is very valid, if you only inject at runtime once you initialize the application, having a 20ms delay is not going to hurt your overall performance. Also there is not a lot of magic happening, I only tried spring boot once or twice but that took more time to get to know how injection is working (BEANS 🥫), and it wouldn't surprise me if that under the hood also uses reflection, especially for field injection and that is not known to be an issue as far as I know.

[Shreyas Patil]

Thanks @joong.lee. Agree 💯

[Shreyas Patil]

In short, Whatever we use for DI, finally JVM server == Use of Reflection.

[christophsturm]

use of reflection != bad

[Shreyas Patil]

I read this article: https://blog.frankel.ch/performance-cost-of-reflection/

[christophsturm]

never trust microbenchmarks

[christophsturm]

ymmv but I’m pretty sure that DI container selection will not even change your startup time anything thats statistically relevant

[Shreyas Patil]

hmm right

[christophsturm]

probably you spend much more startup time in the java classloader than anywhere else

[thanksforallthefish]

in real life, I got the impression that matters so little that while projects like graalvm move a lot at compile time and drastically reduce startup of an application, most of the backend framework actually tries to reduce the configuration you need to write as a developer that they don’t mind using classpath scanning, reflection, and other “slow” operation just so a lot can be autoconfigure for you (at least, I saw this with spring boot, micronaut and quarkus).

[thanksforallthefish]

different is probably if you start using lazy beans, though even then only one request is really impacted, the first one triggering the lazy bean

[thanksforallthefish]

that being said, spring (the one I know the best) is moving away from reflection with kofu and jafu projects, so there are probably benefit to be had there too. so, once more, there is probably no silver lining, find what suits your use case best

[Shreyas Patil]

Thanks @thanksforallthefish