Hello, has anybody integrated http4k with Google G...

# http4k

[Ranganath Kini]

Hello, has anybody integrated http4k with Google Guice?

[Andrew O'Hara]

Not I. In the http4k community, you're much more likely to be counseled to completely avoid dependency injection frameworks, as they don't complement functional programming very well. I would go even further to say they shouldn't be used in Kotlin at all.

[Ranganath Kini]

But would you suggest an alternative design pattern perhaps where dependencies can be injected into the application layers?

[Andrew O'Hara]

In general, http4k is hyper focused on testability. Coincidentally, testable architectures are often be seen as the "best" or "most beautiful" architectures. The http4k maintainers would probably suggest you architect your application in vertical slices rather than layers, but I still find value in the older layered architecture. So, here's two different guides on architecting an http4k app.

Exploring the Testing Hyperpyramid by the http4k maintainers
Writing Testable Kotlin Services by me

[Ranganath Kini]

Thanks @Andrew O'Hara, those are some useful resources. Will explore alternative patterns

[dave]

💯 to what @Andrew O'Hara said. Whilst DI frameworks do have their place when lifecycles are concerned (see android in particular), for the most part we have jettisoned the use of these frameworks entirely.

The general trick that DI frameworks promise is that you need them to help you structure your application in a clean, decoupled and testable way.

However, essentially just using the same techniques (which predate Spring and co) in a manual way will give you a host of benefits without the need to introduce a DI container:

• better startup and testing performance due to manual wiring being much quicker than auto-wiring)
• Visibility and control over every piece of code in your app. Everything happens at exactly the time you expect with you being explicitly aware of it. This helps with any debugging or tracing you might need to do. All exceptions pretty much start at a place WITHIN YOUR CODE instead of at some magic unknown point deep inside an arbitrary library.
• better real terms testability - because you are naturally inclined to structure your layers into testable units - as opposed to having individual objects all present in the same context/magic map).
• better control over how you instantiate and share objects will prevent the need for DI container patterns like Singleton. With manual wiring - you just create one instance!
• better reusability of components and less interfaces with a single implementation. If you create multiple instances of an interface and then have a dependency injected with that interface, the DI container does not know which one to inject unless the receiving object knows which one it wants injected - this is the actual opposite of IOC!
All this comes with the tradeoff of the developers needing to take more responsibility for the wiring of their apps than when using a DI container. Some people might see this as a downside, YMMV.

[James Richardson]

The speed difference between constructing an app or system with actual code and using a DI system (I'm not really a fan of "wiring" - in my mind very coupled to spring) is quite phenomenal.
You'll be writing tests that run in milliseconds. When scaled out across an organisation this is great. For a system recently the whole clean test cycle took 12 seconds, running hundreds of tests, including setting up and onboarding users, all features etc.

[Ranganath Kini]

@dave, @James Richardson, thanks for sharing your perspective. Its just that as a Java developer, I am so habituated to using a DI framework, that we tend to find the same kind of patterns and techniques in any new technology/language/framework and library. Part of this is the lack of understanding of classic design patterns, lack of up-to-date resources and the hyperactive promotions, community engagement from the likes of Spring, Quarkus, Micronaut. Hence newcomers like myself find it hard to fallback to classic "wiring" patterns.

[Andrew O'Hara]

I'm not sure if you've tried quarkus or micronaut, but you'll probably feel much more at home there than you would with http4k or ktor.

[Ranganath Kini]

As a matter of fact I have tried Micronaut. I am not averse to not using a DI system, and curious to apply the classical OOP/FP design patterns and good practices. Just want to understand if there are some good resources which suggest guidelines on structuring solutions without DI with the likes of http4k

[James Richardson]

you could take a look at "Java to Kotlin" (https://java-to-kotlin.dev/) or "From Objects to Functions" ... https://pragprog.com/titles/uboop/from-objects-to-functions/ -

[Ranganath Kini]

@James Richardson, this is awesome. Will dig into them. 🥸

[James Richardson]

👍