Ktor is an interesting web framework. I’ve learned it for several months. But is it ready for building a software product?
And, Ktor vs Spring with Kotlin, which is better for Kotlin web development?
1 Like
We use Ktor Client and Spring for last year. Both are the best for their roles: Spring has a lot of components and large community. Ktor Client works perfectly with non-blocking approach.
If you need small application without any IoC or something, Ktor can solve the most of your tasks.
However if you need huge one with potential integration with Kafka, multiple databases, IoC in tests, etc., then I recommend you to select Spring as more widely used approach in Java Enterprise.
However please note this is just my experience and my advices.
4 Likes
As @imanushin said it depends on the scale. Ktor is perfect for small scale application with no external integrations. I am using it for small services and quite happy with it. Spring now has nice kotlin integrations, but its main niche is enterprise applications. It does not make sense to use it for something small and simple.
3 Likes
Is Ktor fit for scalable web server ? Suppose I want to build a small server and I want to expand it in the future.
The word “scale” has two meanings: “performance scaling” and “functional scaling”.
Ktor corresponds to the both of them. You can configure different serialization, models, etc. for different endpoints. You can write your custom conversion and error handling logic, you can facade logging, etc. Of course you can support several authorization techniques (for all or parts of endpoints).
In case of performance: as I know, at least YouTrack uses ktor, which can be proof of the library power.
5 Likes
Thank you. 
Have you built a website with Ktor?
Hi, @phucynwa,
usually it is quite hard to answer to the question: is a software production ready?
Moreover, it is not possible to mark a product as a “silver bullet”.
Feel free to choose your preferred solution, in my opinion there is no reason to not consider Ktor as a good back-end.
3 Likes
Yes, however it is internal and isn’t heavy loaded (average load is about 1 request per second in a peak time).
Why is it so slow ? 
I’m building a multi DB soon to production backend with Ktor and I must say, it has many clear edges over Spring.
The advantage is the philosophy behind Kotlin: concise and safe. I could pass an entire Ktor codebase to a neofite and he/she could be able ctrl+click everything and follow each and every flow, which by the way are mostly declarative and ence intuitive. Also coroutines in an inherently async context are godsend.
Writing a feature to incorporate code is not hard and, again, intuitive.
With Spring, good luck finding out which annotation is declared who knows where invoked by who knows who.
Indeed Spring has already proven to be worthy and frankly I doubt you could squeeze a better web framework given the limitations of Java (at least compared to Kotlin).
I am sure Ktor will find a way into the Kotlin backend world, It just needs time to find the trust of the devs!
Also, I love Ktor <3
8 Likes
Do you have an open source built with Ktor ? I want to reference. Thank you.
Well, I cannot share them because it’s a business project.
Have a look here instead.
It’s a university project where I used Ktor+Docker. It’s not much but it’s something!
1 Like
Wow, so is Ktor used for your business project?
Well yes, that was my point! 
How do you compare it vs Node.js ? Performance and cost of time ?
Both of them way better. The only comparison that may stand a chance is with Spring!
1 Like
How do you compare it vs Node.js ? Performance and cost of time ?
I’m not sure that we can simple to compare them.
First of all, JavaScript is single-threaded. You couldn’t have shared mutable object (for example - cache) between simultaneous threads. So if your code doesn’t need any caching, any shared state or something, NodeJS can be effective solution. Otherwise JVM/CLR work just better for this case.
Another point is that JavaScript isn’t strongly typed. So huge system couldn’t be refactored safely. TypeScript can help, however you still have library interaction with the same side effects. And this can be restriction for project growth in future, because you will need to split your service to smaller, just to have ability to control the codebase. However with strongly-typed language (Java, C#, Kotlin, Scala, etc.) you can keep more items in one process, which is better for productivity and performance purpose in general case.
From the other side, with NodeJS you can simply share the same TypeScript code between server and browser. For example, you don’t need to rewrite validation twice - first for client and second for server.
Of course there are more pros and cons for this selection, I just highlighted part of them.
5 Likes
we used ktor in production in my previous work, and had very good experiences. sometimes missing the full blown power (+documentation) of spring, but besides that: i have the feeling of never wanting to go back to “annotation based programming” with spring, and rather use a proper programming language like kotlin 
8 Likes
I would say, if you’re starting from scratch then Node.js is by far the best choice right now. If you want static type-checking (and you should), TypeScript is way more powerful typing language than Kotlin. Kotlin is not without its advantages, like its Standard Library which is the best STL out there, but TypeScript is just more expressive. Node.js also has better community and better libraries than Java ecosystem, which is very outdated. Async programming is also way easier in JavaScript than Kotlin coroutines, which are extremely hard to grasp.
If you have a Java/Kotlin source code already, we did an analysis for our medium-sized web service to transition from servlets, and we chose Vert.x. Ktor seems attractive, but due to the lack of event-loop it can only handle simple use cases. Not only does Vert.x plays really well with Kotlin coroutines, it adds to them a very useful concept of event loop which coroutines lack.
EDIT: Spring is just garbage, so I don’t mention it here.