Good morning! I’m looking into kotlin as a server ...

# server

[Andreas Du Rietz]

Good morning! I’m looking into kotlin as a server side language (api’s & workers). What frameworks are recommended? We’re not a fan of spring’s approach on java with loads of annotations and magic. Prefer the style of akka-http or playframework on scala if anyone is familiar with them.

[Flo Wengelewski]

https://ktor.io/ maybe

[dave]

If you're looking for Kotlin-first, then Ktor and http4k are the most prominent. They are also both anti-magic and have friendly local support on this slack. :)

But also, lots of java frameworks work well with Kotlin so don't discount them out of hand and may support features that aren't available in pure Kotlin. Jooby is my personal favourite for java.

Also consider if you want serverless, multiplatform or to work with native (graal/quarkus) so you don't limit yourself there.

[dave]

For instance, ktor is intended to be multiplatform (or if not now then in the foreseeable future - citation needed 🙃), and http4k has support for both serverless and graal

[Andreas Du Rietz]

Thank you! I’ll look into both. Only ktor supports non blocking servers?

[dave]

At the moment, yes. But if you're looking at this from a performance perspective, then bear in mind that even non-blocking servers are backed by threads on the JVM. Worth checking out benchmarks if you're really bothered - but TBH if you were only discounting Spring because of the annotations then I'm guessing you probably don't have that concern anyway. 🙂

[tddmonkey]

@Andreas Du Rietz we quite happily run a 100% kotlin stack on Dropwizard - magic not included

[Andreas Du Rietz]

Can’t say that I’ve worked with a “blocking system” that’s had any scale to talk about. So my experience with moving from blocking -> non-blocking, solving a performance issue is non existent. 🙂 But I’ve been schooled by scala & the reactive manifesto that non blocking is good practice & should be used.

[dave]

Having written frameworks in both blocking (http4k - kotlin) and non-blocking (fintrospect - scala) styles, I can sympathise - but for the vast majority of cases I'd argue that what really matters is the ability to develop and operate systems easily because compute is cheap and developer time is expensive. Traditional (Future-et-al based) async code has the downsides that the model tends to bleed into all aspects of your codebase, which increases complexity in both dev, test and maintenance for your entire app. Now the coroutine model does mitigate this to a certain degree (at least in the aspect of code style), but the underlying complexities still exist - they're just hidden and when issues occur then they may be as difficult to deal with.

Here's a story about Netflix that might be worth reading:
https://medium.com/netflix-techblog/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c

"While we did not see a significant efficiency benefit in migrating to async"
"We have a system that is much more complex to debug, code, and test"

[Andreas Du Rietz]

Good point. I consider myself pragmatic and have no desire to write code that’s not really needed 🙂

[kenkyee]

Also worth considering are Vert.x and Micronaut and Quarkus.io...all support GraalVM for better speed too (though that depends on the libraries you end up using because not all 3rd party libs will work w/ GraalVM).
And Spring has a non-annotation mode now if you look in the #spring channel...

[Tom Prior]

@Andreas Du Rietz I havn’t used this yet but I’ve heard good things about it - Spring Kofu with explicit configuration using a kotlin dsl https://github.com/spring-projects/spring-fu/tree/master/kofu

[kenkyee]

Spring Fu is like a labs area for Spring...I wouldn't go into production with it IMHO...