I’m not going to use ktor as a network client anymore, here’s why
There is a lot of hype around ktor: numerous posts on Twitter, Medium, podcasts, and more on how everyone should jump into using it. Let’s take a step back and try to understand the big picture.
Software engineering is a game of tradeoffs: you win in one place but lose in others. So what’s the deal with ktor? There are clearly 2 tradeoffs made with the overall concept of ktor:
- Ktor is multiplatform: it strives to support different platforms such as JVM, JavaScript or Native
- Ktor is concise: it emphasises easy to write code
Do you feel the loophole in this? I certainly didn’t and boy was I surprised when I received this issue.
You can certainly ignore the context of the project where I’m using the ktor, but here are some important facts about the desired use-case:
- Ktor is used as a TCP client
- Ktor is used as a coroutines-based API for filesystem IO
- The load on the client is burst-based: there is no need to handle a lot of connections at the same time, but the throughput of each socket is of particular interest
What I’m interested in a client boils down to the following needs:
- Performance: I need to move bytes as fast as possible
- Reliability: I need to be sure the code is tested for different edge-case scenarios. TCP/IP is not rocket science, but it’s not simple either
Neither of these is a priority for ktor and herein lies my biggest mistake: I chose a tool that was not designed for my particular problem.
Let’s dive into the stages of my grief with ktor.
Denial
Recap of the issue at hand: the performance of reading a file and pushing it over a TCP socket degraded significantly. Surely, this must be an issue with the user’s setup. After all, I’m using a highly popular framework with 8k+ stars on GitHub! Right?!
