
Show HN: Http4k: Server as a Function. In Kotlin. Typesafe. Without the Server - tarkaTheRotter
https://www.http4k.org/blog/meet_http4k/
======
tarkaTheRotter
Hi. Library author here - we thought we'd commemorate our v3.0.0 release -
which adds AWS Lambda as a as a server(less!) backend - with a self-
congratulatory post. We hope you like our stuff :)

As you might have guessed from the version number, http4k isn't actually that
new - we've been using it in production with significant traffic (in the top
1000 globally according to alexa.com) since March so it's thoroughly
battletested in the wild.

AMA.

~~~
pritambarhate
Thanks for sharing your work. Looks quite impressive. A lot of your ideas
resonate with me. Mainly "no annotations, no reflection" part. All the
reflection magic makes spring apps painfully slow to start.

How long did it take to create this?

~~~
tarkaTheRotter
All in? About 15 years of being frustrated at various frameworks... :)

More seriously, we had a pretty good idea of how we wanted the main interfaces
to look - the current HttpHandler and Filter file
([https://github.com/http4k/http4k/blob/master/http4k-core/src...](https://github.com/http4k/http4k/blob/master/http4k-core/src/main/kotlin/org/http4k/core/Http4k.kt))
file is only 19 lines long - so the actual implementation was pretty quick! :)

Previous to that, we started out with a 40 line Kotlin script which wrapped
the API of an awesome Java framework called UtterlyIdle. However we soon
wanted to begin using pure, idiomatic Kotlin, so eventually decided to start
again and port what we needed. The simple routing API was also pretty easy,
although the ability to infinitely nest routes in concert with the Filter
system came later.

Timewise, we've been in prod with http4k since about March - here's the github
contribution graph
([https://github.com/http4k/http4k/graphs/contributors](https://github.com/http4k/http4k/graphs/contributors)).
A lot of the effort since has been for adding the various modules as we needed
them - AWS request signing was interesting, as was adding Multipart support
(ported from a Java implementation by @tiestvilee who you can witness being
sarcastic further down this thread :).

Personally, the most complicated (ie. time-spent) bit to get right was
probably the Lens API- there were several iterations of that until it was as
clean, and we learned a lot about the language at the same time - for
instance, that you can define extension methods on a Kotlin Object and then
import them from that instance - thus allowing you to have different versions
of the same extension method happily coexisting.

------
kod
I don't see how ignoring async is going to turn out well for this project.

~~~
kjlkjasdfasdfda
What would you expect?

type AsyncHttpHandler = Request -> Future Response

type AsyncHttpHandler = Request -> (Response -> ())

or use green threads

------
tiestvilee
How fast is it? Is it webscale? Why do I need types? Does it include
dependency injection? Can I use it with Spring? Is it compatible with
ActiveRecord? Will it compile my javascript to WebAssembly?

~~~
justbaker
Are you actually expecting useful answers from poor questions?

------
gypsydave5
I've always liked the simplicity of Http4k framework - the isomorphism between
the servers and the clients is a great feature.

------
puug
Very cool. How does the roadmap for this compare to similar minimal
implementations like ktor?

~~~
tarkaTheRotter
First off, the most important thing for us is to keep the APIs simple, sane
and consistent. We absolutely won't add anything in a rush, or if it means
compromising that core principle. :)

There are various things I'd like to add - simple plugin modules for metrics
(dropwizard or prometheus), security (probably pac4j) and typesafe session
support (via lenses) are in there. A sane websocket api seems to be a popular
request so we'll also probably look at that.

Async would probably be via coroutines as that seems to be the nicest option
API-wise. If it did work out well then we could probably backport it and
piggyback the sync api on top.

The serverless stuff is interesting as well, although that's more around the
deployment tooling at the moment - we'll see what happens if Google and MS get
involved, or how the tooling develops for things like terraform.

Other than that - we'll happily accept suggestions! :)

------
quii
Is this as good as Play! framework?

------
kjlkjasdfasdfda
I'm not a user of Kotlin but this is really nice.

