why choose ktor when there's spring boot
# ktor
b
why choose ktor when there's spring boot
h
Personally, I like the lightweight dsl, and the naturally async nature of it.
b
doesn't spring boot have the same with webflux + dsl?
n
Spring Boot is known to be very heavy weight and does tons of magical things, which are very difficult to troubleshoot when things go wrong.
b
is the "heavy weight" noticable in benchmarks?
I'm asking because I want to work with DI in all cases and it seems like ktor just has more setup for little benefit
n
Check out the Techempower Benchmarks: https://www.techempower.com/benchmarks/
b
looks roughly equivalent I guess
ah, my bad
ktor 80k, spring 30k
so basically small requests will scale twice as much
what about vertx btw?
n
Current rankings of Spring as follows: • Fortunes - 190 • JSON Serialisation - 202 • Single Query - 144 • Multiple Queries - 185 • Data Updates - 101 • Plain Text - 179
Current Vert.x rankings: * JSON Serialisation - 14 * Single Query - 1 * Multiple Queries 3 * Fortunes - 2 * Data Updates - 3 * Plain Text - 27
b
vertx is probably faster because the api is much lower
but not sure how close a typical web app is in terms of performance if you build it on either framework
d
if you like spring boot and you're on the JVM, there's really no reason to switch
r
I like ktor better mostly because it behaves more like a library than a framework. It gives you more flexibility and is easier to handle, you can for example very simply just start a webserver from your code. Also, it imposes no DI method on you - it's a webserver, and that's it, if you want DI you can choose your own way to do it. In Spring your are meant to use their DI, with lots of annotation- and reflection-based magic that produces unweildy stacktraces and is hard to debug when stuff goes wrong.
That being said, as @david-wg2 mentioned, there's nothing wrong with preferring the way spring does things, or simply sticking with it because you're already using it and it works fine.
a
It depends on what your requirements are for a project, and your team setup to make these kind of decisions. Spring is opinionated, which isn't bad. When starting with a team everyone knows how to work with it and how it should be structured. This could be a good thing when starting a project or a team which have difficulties to make those decisions. the downside is like already stated a lot of work is being done for you, when shit hits the fan it might be difficult to figure it out. micro-frameworks like ktor have the advantage to cherry-pick the best libraries for your project. but it will require more discipline from your team on how to setup it up and how to structure it properly. if some goes wrong in this case, probably it easier to understand where the issue is coming from. Also upgrading/changing individual modules is more easy. in the company where I work we use both. spring is rich in features we use it where needed. but for most services we do tend to prefer micro-framework as we don't need to use as much features