Hacker News new | comments | show | ask | jobs | submit login
Show HN: Http4k: Server as a Function. In Kotlin. Typesafe. Without the Server (http4k.org)
29 points by tarkaTheRotter 10 months ago | hide | past | web | favorite | 12 comments

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.


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?

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...) 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). 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.

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

What would you expect?

type AsyncHttpHandler = Request -> Future Response

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

or use green threads

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?

Are you actually expecting useful answers from poor questions?

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

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

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! :)

Is this as good as Play! framework?

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

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact