I don’t want to derail <@UJ31794BC> question above...

# server

[Emil Kantis]

I don’t want to derail @Luiz Aguiar question above, but what makes Ktor a non-contender in these cases? 🙏 @nfrankel @Richard Gomez

[nfrankel]

i don’t have experience with ktor
however, as far as i know, it’s “just” a web framework
all others mentioned have batteries included: dependency injection, externalized configuration, etc.

[dave08]

For configuration https://github.com/sksamuel/hoplite is pretty good. As for DIs there are plenty out there... Kodein, Koin, Dagger2 + Square/Anvil... you could always match and mix.

I think those have many more modules, apart from that... caching, service discovery, and TONS more... and they're built to work together in a similar philosophy.

[nfrankel]

@dave08 that’s my point
you need to do your own stack and hope that they play well together
with frameworks, it’s in-the-box

[antonarhipov]

ktor is more like an http toolkit. It doesn't provide as many integrations out-of-the-box as Spring, Quarkus, or Micronaut. For instance, there's no integrated database support in ktor - you'd need to choose a library for database access and then make up your own way to configure. It's not hard at all, but it's kinda inventing your own wheel every time. Some people like this approach more - then they can build their own stack and tailor it for their needs. IMO, it's a matter of taste.

[Richard Gomez]

I don't have experience with ktor either, but I agree with @nfrankel's assessment.

My go-to http toolkit is actually Vert.x, which has an event bus and is reactive/non-blocking. I find the non-blocking ecosystem is a perfect fit for coroutines, and it's easier to 'reason' with than trying to piece together blocking + non-blocking.

(Admittedly, I still don't know the 'proper' way to read a file from a coroutine. IntelliJ complains when I wrap Java.NIO in a <http://Dispatchers.IO|Dispatchers.IO> context.)

[dave08]

Ktor is built with non-blocking in mind @Richard Gomez... you can run coroutines straight in the routes themselves like in Vertx. If all you need is an http client/server framework, Ktor is a nice/lighter alternative, especially with the new 2.0 server that will be able to compile to kotlin native or GraalVM, which competes with Micronaut and Quarkus... but if you need all the other bells and whistles, I think that he's right too... but my point is that these humongous frameworks can sometimes be avoided if you add a few good/tested components to Ktor.

[Richard Gomez]

Ktor is built with non-blocking in mind @Richard Gomez... you can run coroutines straight in the routes themselves like in Vertx.

@dave08: I meant to say that Vert.x is similar to Ktor, not that Ktor isn't non-blocking. The benefit of the "ecosystem" that I mentioned is that it also provides non-blocking IO, database drivers, messaging clients, etc., whereas with Ktor you'd need to choose libraries yourself, like Anton mentioned.

However, Vert.x isn't a humongous framework. It's a toolkit that happens to include an HTTP server. There are probably people using Vert.x's non-blocking database drivers in a Ktor project.

[dave08]

Did you see #jasync-sql? It's a port of those db drivers to Kotlin (also purely async), including a coroutines wrapper... in the beginning I was using vertx for that, but after I discovered jasync, it didn't justify the extra complexity in our case... now we're between Ktor and Micronaut for all our microservices,

[Emil Kantis]

I started setting up a project for a minimal but complete stack using Ktor. Do you have recommendations of things to include @dave08 ? Repo here https://github.com/Kantis/ktor-starter

[Emil Kantis]

I've felt a bit frustrated at times with Spring. Even though it's evident that they put a lot of effort into supporting Kotlin I feel it shows at times that it's not a kotlin-first framework. For instance my discussion in #spring related to Cacheable.

[Richard Gomez]

@Emil Kantis: That's my experience with Spring as well. Features and documentation for Kotlin are often incomplete or missing, which is doubly frustrating because features and documentation for WebFlux are often incomplete or missing.

[Luiz Aguiar]

I think the biggest drawback of the very good points described by @antonarhipov is to have this in a "big" scale, with multiple teams and projects, onboarding new devs that will have no clue what they can find. Ofc it's possible, but it's not that easy for every company.
It's really cool and exciting on the technical side, but it can get messy and have big impacts in productivity.