^ massively biased choice as I'm an author of http4k

I found this http://sparkjava.com/tutorials/kotlin looks nice and have docs about the framework api

@juliocbcotta Yes - docs is currently something that we're definitely looking to add more into for http4k. We're working on a number of things including more fleshed out documentation about the various modules that we've got so far and at least one guide of how to develop an app using library from first principles. On that note, if anyone can recommend a static site generator for this kind of thing we'd happily take suggestions so we can put something proper up at http4k.org! 🙂 At the moment we've been concentrating on showing full examples of working services - there's a cookbook section in the src and a complete TDD'd example app in the readme that demonstrate most of the features of the library. Anyway, to enhance on @s4nchez's answer a bit, it's might be a good idea for people to actually communicate why they are using the stack that they are. For us, http4k is the distillation of 15 years worth of server-side libraries that we've used and we've stolen good ideas from everywhere we can. For instance - the routing module is inspired by UtterlyIdle, the "Server as a function" and filter model is stolen from Finagle, and the contract module/Swagger generator is ported from Fintrospect, Now that we've got Kotlin (yay!), we wanted something that would fully leverage the features of the language, so it seemed like a good time to start something from scratch. For our purposes, we needed something that 1. starts/stops ultra quickly, 2. easily testable outside of an HTTP container 3. provides typesafe HTTP message deconstruction/construction (in this case via Lenses) 4. Automatically deals with contract breaches (missing/invalid params etc) 5. No magic involved - No reflection. No annotations. (this is our preference due to being burned by DI containers 🙂 6. Minimal dependencies (http4k-core has zero) 7. Automatic generation of Swagger documentation (including JSON Schema models). 8. Has a symmetric server/client API (HttpHandler should just be Request -> Response). 9. Has immutable Request/Response objects - this is quite rare when coming from Java libaries All of these things summed together allow us to construct entire suites of services which can be tested either wired together without HTTP, or spun up in containers in 1 LOC. The symmetric HTTP API also allows filter chains (often called interceptors in other frameworks) to be constructed into reusable units/stacks for both server and client sides (eg. logging/metrics/caching...) since they can be composed together for later use. We can also easily create simple Fake servers for any HTTP contract, which means (in combination with CDC suites) we can end-to-end test micro-services in an outside-in way (using GOOS-style acceptance tests). This means that you are easily able to answer questions like "what happens if this HTTP dependency continually takes > 5 seconds to respond?" - which is a question you can't easily answer if you're faking out your dependencies inside the HTTP boundary. Hope this all makes sense - sorry for the rambling! There's probably a blog post in here somewhere.... which is another thing to add to the list! 😞

Add to #5: no reflection. No annotations.

I will take some time to study it a bit more. It looks like there are a lot of web/rest frameworks I can rely on, but I am a bit scared of dealing with databases. Any orm or database framework well documented do you guys recommend ?

@juliocbcotta for my current project I end up with MongoDB and Morphia ODM, they are quite simple to handle and they are also well documented

@juliocbcotta a famous person once said "ORM is the Vietnam of computer science" :)

We tend to stick with raw sql + hikari for pooling

the problem with raw sql is that is it too easy to introduce sql injection problems and having to deal with sintaxe errors is just a pain.

Prepared statements get around the injection vectors afaik.

In our experience, if you abstract too far from the SQL, you're left exposed by not being able to tune queries properly.

@dave http4k looks great. Are things like websockets going to be supported? I'm not quite sure how they'd fit into the

(Request) -> Response

model.

@juliocbcotta We use Dropwizard for servers with variations for the rest of the stack. DI: Guice or manual preferred, sometimes Spring Persistence: JDBI or Hibernate or Eclipselink

Persistence: ORM (Hibernate in our case) for inserts/updates, RAW SQL for queries mostly

Our stack: HTTP: Ratpack Dep. injection: Dagger 2 Persistence: jOOQ (awesome... seriously, fuck Hibernate!) HTTP to other serviceS: OkHTTP Testing: Spock + Mockito (Spock's native mocking & stubbing doesn't play too well with Kotlin)

..plus gradle, asciidoctor and a bunch of other bits

Oh yeah, Netty for sockets (it's a game server so part of the protocol is based on sockets)

@andrewoma at the moment we haven't looked at websockets, although there is W/S support on all of the server backends that we have (Jetty/Netty/Undertow) and all of the backends have an available API for inserting your http4k app into a customised server instance . We could probably add a new abstraction around these various backends and provide a standard unified interface in the core module, but you're correct - the core Request -> Response abstraction doesn't hold for W/S.

@dave just read about you using SQL and I can't recommend jOOQ enough, it's awesome: https://www.jooq.org/

@juliocbcotta HTTP endpoints: Hexagon http://there4.co/hexagon (https://github.com/jaguililla/hexagon) Persistence: Hexagon (MongoDB) HTTP requests to external services: AsyncHttpClient E2E tests: Cucumber + AsyncHttpClient

@jaguililla Why Jetty is not embedded in the framework?

hope you don't mind newbie posts here, but how do I start with learning server development in Kotlin? I have no Java background

Hi @jackmiras, the framework is designed to support different server implementations.The goal is to provide a library to define routes and their handlers and delegate the runtime to other libraries/frameworks. This way, you can keep your programs unmodified and change the underneath implementation

@tadas44 many people use spring bootstrap, you could take a look at that

Thank you @christophsturm, how about other frameworks? It can be API only, no Web support

I would stay away from anything Spring if you're learning how to build a server. Start from the basics and build things from scratch so you can understand them.

Would Spark be a better starting point @cedric ?

(sorry to immerse myself in the discussion)

I'm not a fan of SparkJava because of its reliance on statics everywhere. If you want to start completely bare bones, I'd go with jetty and select the components you need one by one. It's a bit painful but it will teach you a lot about the whole server stack. If you want to start a bit higher level, use DropWizard, which includes low level frameworks so you can focus on higher level things such as creating JSON API (which is probably the first thing you should learn as an Android developer).

(you = OP, sorry for the confusion)