ok guys need to go, it was a great discussion! looking forward to meet some of you IRL at KotlinConf soon 🙂

see #spring

spring have kotlin support at now

Also, it has scalability as microservices, with an eventbus for communication and supports scheduler infrastructure like kubernetes...

I look at features not marketing🙂

I have made a DSL to run a Spring WebFlux Application in a functional way

fun main(args: Array<String>) {
    webfluxApplication(Server.NETTY) { // or TOMCAT
    
        // group routers
        routes {
            router { routerApi(ref()) }
            router(routerStatic())
        }
        router { routerHtml(ref(), ref()) }
    
        // group beans
        beans {
            bean<UserHandler>()
            bean<Baz>()  // Primary constructor injection
        }
        bean<Bar>()
    
        mustacheTemplate()
    
        profile("foo") {
            bean<Foo>()
        }
    }.run()
}

The project is here : https://github.com/tgirard12/spring-webflux-kotlin-dsl

I'm very happy with Ratpack + Kotlin, the code is not in production yet, but will be by the end of the year if all goes well

Can't compare to Vert.x or KTor because I haven't used them, but it's refreshingly light compared to Spring

..not that I have anything against Spring, but I feel like I'm spending more time solving my own problems instead of Spring's and it's a good feeling 🙂

(on the other hand I've been using Spring for years and I like to try new things, so maybe it's just Spring fatigue 😛 )

What's nice is that all the main Java server frameworks have embraced Kotlin. That said, they do basic REST API stuff, but what is important is how easy it is to add other functionality that's expected nowadays: scaling, social login, distributed logging, metrics, etc. Not everyone needs all of these, so it really depends on what you need 🙂 Vert.x and Spring Boot both do everything (scaling is simpler w/ Vert.x). Leaner frameworks like Ratpack and SparkJava don't but are slimmer.

@kenkyee keep in mind that Vert.x is very modular and you can stick to vertx-web and the tool of your choice and get something comparable

For basic rest APIs, everything is pretty much similar.. You always have to define routes and parameters 😀

@kenkyee maybe things look similar, but I'd add these questions into the mix: 1. can you modularise routes (for reuse) and nest those modules under common contexts? 2. Is the parameter extraction typesafe and how do you extend it to define your own types to (de)serialise? 3. How does the API cope with required/optional/defaulted parameters, or the multiplicity of those parameters? How about failure - do 400s get generated automatically? 4. How do you add request pre/post processing or app agnostic behaviour? Can those behaviours also be modularised? 5. Is there a model for form submission which includes error collection for invalid fields? 6. What about outgoing HTTP clients - is there a symmetrical model for outgoing requests - which means developers only have to contend with a single HTTP API and you can plug suites of services together in-memory? 7. Testing - can you test routes out-of-container and how easy is it to compare expected responses (in pure kotlin, we can use data classes for this)? 8. (Also testing): how much custom infrastructure is required to test routes or apps? This matters because your endpoint tests should be decoupled from your implementation, so at the very least it should be made easy to reuse tests at different scopes by just switching out the underlying client - or even switch out the impl entirely if you move to another framework.

6 looks like selling specific benefit of http4k 🙂 It’s not a requirement per se. Client and server models are significantly different.

@orangy Probably guilty as charged 😀

@orangy also - I'd be really interested to discuss the differences between them.

(Although maybe not this late in a Friday! 😉)

Right 🙂

Most people asking which framework to use probably haven't thought that far 😉 For the most part though, those things have been addressed by most frameworks...Jackson for de-serializer, validation libraries, route DSLs for Kotlin, RESTassured for testing, metrics like dropwizard, etc.

@orangy "Client and server models are significantly different." I'm curious to hear what are those differences. HTTP messages are the same on both ends of the wire, and there are great benefits of embracing that. Specially nowadays where writing servers that talk to other servers is such a common scenario.

@s4nchez even if the message format is the same, there are many differences. E.g. client is (mostly) using one request, while server handling many. There are differences in lifecycle. Server receives a request and produces a response, and thus there is single “window” of execution when you have both: request received and response being built. Client has two “windows”: it produces a request using builder, and it doesn’t have a response yet, then it sends a request and receives a response (both are available, but none are builders). So the API should be reflecting the differences in lifecycles, mutability, asynchrony, etc.

I appreciate that lifecycle is important for frameworks. And is a shame that web frameworks don't consider consuming other services a 1st class concern.

And when it comes to concurrency and mutability concerns my experience is that their requirements tend to be very similar regardless if one is serving or consuming http.

Huh, looking at that list from @dave I feel the framework I'm using ticks almost all of these; wouldn't it be interesting to have a comparison page that would allow any JVM web framework to register a Github example project and then link them to a requirement on that page? e.g. _Modular routes allowing reuse ... _ - Ratpack: https://github.com/ratpack/example-ratpack-gradle-kotlin-app/blob/6909bee8aec29a6bc737e2c0a79423757aa9062b/src/main/kotlin/ratpack/example/kotlin/Main.kt#L29-L54

Projects can then register themselves on the page

..it could be a simple webpage on Github, anyone who wanted to contribute their example would only need to issue a pull request

(don't look at the example link, it doesn't neccessarily "prove" that Ratpack fulfills that requirement, it's just an example)