So far, in most of the places where we've been inv...

# http4k

[s4nchez]

So far, in most of the places where we've been involved directly I can say that adoption happened somewhat organically. We are either invited to do talks on http4k or provide consulting on wider topics, so in a sense we never pitch http4k directly but rather use it as a tool to contribute to project success.

If I had to pick the biggest pain point we solve is testability, and we've been lucky that most teams we see will quickly embrace http4k when they experience how much simpler it makes to write powerful, super-fast tests. I also never saw people miss their DI framework when they see that wiring an app by hand is easier when you design it sensibly.

The kind of resistance we face tends to be either from people not bought into Kotlin yet or those who default to Spring as career choice and are happy to reject anything else. We also get the usual question about async sometimes but in practice I don't remember facing a single production scenario where that turned out to be a problem.

[Philipp Mayer]

Thanks for that extensive answer!
I agree, especially about the testing argument. Still, it's hard to even convince people that there is a world without DI (or Spring..), hence I'm always interested how other people accomplished that.

[James Richardson]

Perhaps it's just a matter of language/terminology. A lot of people equate DI with spring, or other framework and think its impossible without a slow and complicated framework. However, of course using a constructor is just the same. Once people understand this, they can sometimes be very enthusiastic about constructors! You "inject" the object dependencies using a constructor, and that's it! No annotations, no xml, no scopes, no reverse dependencies...