Random question and not a request to deliver. The ...

# kvision

[Phil Richardson]

Random question and not a request to deliver.
The choice of DI was Guice, Is there a reason why this was chosen over other DI frameworks, such as something more Kotlin first like Kodein-DI?

I have found Guice to be a steep learning curve and requires way more boilerplate for the same goals.
I can use Kodein via JSR-330 support with limitations (plus I don't want to kill the kittens the docs warns about), but I believe may prevent its use anyway.

[Robert Jaros]

The first framework supported was Jooby (Jooby 1 to be accurate), and it was based on Guice.

[Robert Jaros]

I'm not even sure there was any Kotlin DI framework available at that time.

[Robert Jaros]

Also it's not easy to find documentation / tutorials about integrating DI framework with all those supported frameworks. I need to integrate with Ktor, Javalin, Jooby and Vert.x. I was able to find some docs in Google about Guice in all four frameworks. In case of Koden-DI I can find Ktor and Javalin but nothing about Jooby and Vert.x.

[Phil Richardson]

Ahh. Yes, that's the context I was not thinking about.
I had too much focus on use of Ktor and thus, too much on Kotlin First, when a lot of those integrations may not involve Kotlin directly.

I have enough Guice knowledge now to get to where I need, but generating Providers feels so unnatural and with code syntax that feels overkill. Kodein has spoilt me I suppose.

[rocketraman]

I use Kodein-DI too, and also found the use of Guice in kvision to be a bit of a stumbling block. I ended up instantiating a Guice module as a Kodein dependency, passing other dependencies into it, to bridge the two systems. But its boiler-platey.

[Robert Jaros]

There three things needed to integrate DI with KVision.
1. creating bean instances on every call (default in guice, prototype scope in spring/micronaut)
2. access to the instance of some kind of configurable context (child injector configured with modules in guice or global spring/micronaut application context)
3. ability to get bean instance from the above context by class type with a call like val service = injector.getInstance(serviceClass.java) where serviceClass is KClass<T>

[Robert Jaros]

If these are all available in Kodein, I could probably try to implement ktor+kodein kvision module

[rocketraman]

All of that is possible with Kodein

[Robert Jaros]

What about Koin? Isn't it more popular?

[rocketraman]

Beats me

[rocketraman]

It feels like there should be a way to abstract away both the DI and server layers.

[rocketraman]

At least for DI... so instead of supporting each DI, use whatever you want internally (stick with Guice for example), but don't expose that to the outside world. Create some interfaces that allow the outside world to give you what you need, and then people can figure out their own mechanism for implementing those interfaces.

[Robert Jaros]

Sounds great 😉 But that's a lot of work ...

[rocketraman]

Yeah, just spitballing. kvision v6. Or 10. 🙂

[Robert Jaros]

And I'm using Spring, so all that DI mess just does not motivate me much 😉

[Robert Jaros]

Still it's an interesting feature, so I'll think about this 🙂