The company where I work is switching from Clojure...

# http4k

[Brett Rowberry]

The company where I work is switching from Clojure to Kotlin. Most of our development is internal web services running on k8s (EKS) in AWS. The first Kotlin service was built using Spring Boot. Coming from Clojure, I'm hoping for something more data and function oriented than OOP. Any thoughts on why we'd be happy or regret switching to http4k? We use SQS, PostgreSQL, Kafka, and call a lot of third party APIs.

[dave]

(partisan take incoming!)

Coming from clojure, you're going to find http4k much less of a culture shock than using spring with its auto DI and annotation magic, and appreciate http4k's functional style, superior testing techniques, and general power of the SaaF paradigm. It's definitely not for every team though - for non http technologies, there is a lot less handholding as we don't try to do everything.

http4k also has many (many) less CVEs than spring if you're interested in that type of thing. We recently ran the entire codebase through Claude and proactively patched a lots of hardenings from 9 years of code (we also found a couple of CVEs which we prepatched for release before disclosure). You can read about that here.

But I of course am exceptionally biased, so will happily leave it to anyone else here who wants to chip in with their own experiences🙃

[Andrew O'Hara]

(And here's me who unabashedly looks down on Spring users)

You're going to have a harder time hiring people who already know http4k. (In my opinion) Most Kotlin and Java developers don't know how to operate outside of the Spring Ecosystem. Http4k doesn't prescribe specific patterns, and so people accustomed to the structure of frameworks will feel like the rug has been pulled out from under them. But people who actually know how an applications works will feel like they're finally free of Spring's limitations.

Http4k is great for for a small team of expert developers to make something incredible. But if you have a large team with a wide skill gap, you'll struggle to produce consistent quality. Frameworks like Spring tend to normalize output so that experts and novices can all produce meaningful contributions, at the expense of overall quality.

Spring benefits from a legacy of documentation and guides; however it feels like 90% of them are out-of-date, so YMMV. Http4k has very little of either; and while the documentation is helpful, you will absolutely need to read the source code to understand how to use things, or to discover useful features. That being said, the http4k source code is highly praised; it's not like trying to read through Spring or AWS SDK sources, which are a maze of abstractions and delegates.

More to your needs: http4k has its own AWS SDK with built-in fakes for most services. You can run full E2E tests in seconds.

[Brett Rowberry]

Thank you both for your sincere and self-aware responses.

[James Richardson]

If you do use non-http technologies, though, you'll find i think that the same thinking and non-magical approach, coupled with the same fearless testing... Will get you very far quickly. Integrating databases, messaging, computation, etc all becomes simpler when you just construct the app you want.

[James Richardson]

(Disclaimer: I have contributed to http4k too, so probably not 100% objective... but also http4k came from these principles, so thats why for me it makes sense)

[dave]

A slight addendum to my previous answers, and to follow up on those above.

We've found that LLMs are very good at writing and extending http4k using the same functional concepts, which we attribute to the simplicity of the concepts and overall source consistency. This is especially true if you install our agent skill which is updated with every release to include API patterns and techniques.

Andrew's point about team sizes is mostly true in our view, but I'd probably add that a lot of how teams experience http4k may depend on their culture and strength of engineering practices rather than seniority/experience. If you are encouraging practices strong on XP/pairing (which is where the http4k community was born), inquisitiveness, simple/functional design, or test-driven, then that is a perfect match IMHO. Teams that don't relish learning off the beaten track (because they have already mastered X-framework which allows for Y style of testing etc) tend to struggle more to make the most of it. He also misspelled "milliseconds" 😉