Ktor vs http4k

My exploration of JetBrains’ HTTP library concludes today with a comparison of the same functionality implemented with Ktor (ktor.io/) and http4k (http4k.org)
That’s it really. Please watch it to the end and let me know in the comments if you agree with my conclusions.
In this episode
00:00:00 Review
00:02:28 Create a function to create the routes
00:03:35 IntelliJ refactoring internal error
00:04:23 Bind our first handler to GET /customer
00:06:32 http4k JSON support
00:08:16 Bind a handler to GET /customer/{id}
00:10:17 Some trouble binding to a path with no id
00:12:00 Fudge that
00:12:38 A handler for delete by ID
00:14:55 Another route matching differences between Ktor and http4k
00:16:05 Finally a POST for adding a customer
00:18:53 Finally another error case, this time we need to catch
00:20:47 Check the tests
00:21:12 Compare and contrast our two app versions
This video is in a playlist of Ktor episodes ( • Ktor ) and http4k ( • http4k )
If you like this, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style.

[@RefactoringDuncan]

I realised in the edit that I didn’t stress how wonderful the symmetry in http4k is, and how I miss that in other frameworks. The fact that the client and server both work with the same Request and Response and HttpHandler and Filter is freeing. I’ll look at this next episode.

[@FeeshNL]

I love that Intellij had the exact same response to you including a hyphen in a filename as me.
Great video, I've been meaning to try http4k and seeing the comparison has been very useful.

[@RefactoringDuncan]

I’m in the habit of using lower-case file names for collections of functions: saving.kt, printing.kt etc, and I think dashes in filenames are just easier to type and read in these cases. But we all have different tastes.

[@RefactoringDuncan]

It’s good to know that it’s useful material, so thank you. I am biased, having worked in the group that created http4k, but I truly rate it as a world-class piece library.

[@FeeshNL]

@@RefactoringDuncan I've never considered it, I'm a camelcase kind of person though. Only poking fun though, genuinely great content, looking forward to seeing more.

[@Aayar22]

I have seen that there are very less views on your video but still, you are making it for a very long time how do you get motivation for that.

[@lkyuvsad]

6000 people a month considering your opinions is better than most of us achieve in a whole career. Seems pretty motivating.

[@RefactoringDuncan]

This one is very new, but TH-cam says it is the second most popular of the last 10 - I’m seeing a steady growth in views and subscribers over the months. Which is nice, as is the feedback and thanks that i get from people here and in real life.

[@DavidA-fi9jy]

It seems like the main thing that was bothering you was Ktor's mutating routing at each step... but if you look at the DSL as a type of builder, which it is since most of this code is running at startup, then it might not be so bad. And you gain the fact you can run coroutines libraries... I'm sure there's a more generic form instead of post(...)... etc that gets the type of request, so that might not be an issue if you want to have the same handler for multiple route types, and anyways, you could always pass a lambda you saved in a val before in multiple routes.

[@RefactoringDuncan]

It’s certainly true that undetectable mutation during initialisation isn’t an issue, but I do find it interesting that one api requires a context during configuration and the other doesn’t.

[@RefactoringDuncan]

I suppose that I’ve started from the examples provided by the documentation to get a feel for the way that the authors think. Ktor is DSL-based; http4k is building functions with functions. In Ktor it would be difficult to configure serialisation on a handler-by-handler basis; in http4k we have to specify the serialisation in each handler. There are pros and cons to each, I suppose I might characterise the feel as Ktor is more out-of-the-box framework; http4k more blocks that can be composed.

[@RefactoringDuncan]

Ultimately I think coroutines will prove to be an irritation not a benefit for server-side JVM developers who can use Loom. I may be proved wrong!

[@DavidA-fi9jy]

@@RefactoringDuncan Given the amount of libraries currently supporting coroutines and it's KMP support, I don't think it's being replaced by loom in the near future, and the simplicity of handling concurrency with it is great! You just write what looks like imperative code and the concurrency is mostly handled for you... and Flows don't have a Loom replacement for now (maybe RxJava or the likes will/do support it? -- but their complexity compared to Flow is a big disadvantage...)

[@DavidA-fi9jy]

@@RefactoringDuncan I'm not saying I don't like Http4k's composable block approach -- I'm just saying that Ktor's approach isn't really some mutable monster that could explode on you... it's just a builder DSL that also uses functions to handle requests - but instead of (Request) -> Response, you have a context that you get the request from and call functions from it to return a response, which is a better model for concurrency inside that lambda... you don't wait for a response to return from the lambda with it - so you can do a bunch of concurrent stuff beyond the lifetime of the lambda as long as you call the respond function on the context to return a response. And the lifetime of the lambda is, I suppose, the "threads/coroutines" pool that handle the requests that are incoming and should not be blocked... in Http4k, you'd have to open a new virtual thread to run the lambda and get the response without blocking the pool that receives the incoming requests.