I’m always late to the party. I like playing safely and not investing my time in something that might or might not live on a long-term scale. I do not know about you, but I’m 38-year ex-developer, now IT architect, with not enough time to play with any recent and upcoming technology.
 
Come on, some of us here do not have Which brings me to Kotlin.
 
When I think about it, it took me eight years to notice Kotlin. In my defense, it took the Kotlin six years to go mainstream, and two more to be acknowledged and valued by several significant players, among whom Google is probably the most important.
 
While I dislike Google and the way they kill products like there’s no tomorrow, I cannot object their decision to make Kotlin the preferred language for Android development. I invite you, my dear reader, to argue in the comments below if you disagree with me; I like a good challenge.
 
What I want to do in this article is to show you the best Kotlin-based RESTful frameworks. I also apologize in advance, I always find it very difficult to analyze something and remain objective at the same moment.
 
Over time I will update the list below, for now, these are the best five.
 

Contenders

 
These are my chosen seven, sorted in alphabetical order:
 
  • Javalin
  • KTor
  • Spark
  • Spring Boot
  • Vert.x
 
 

1. Javalin

 
Introduction date: 2017 (1.0.0 version)
 
In a nutshell, Javalin is just a few thousand lines of code on top of Jetty. It started as a fork of the Java and Kotlin web framework Spark (find more about it below), which quickly turned into a ground-up rewrite influenced by the Javascript framework koa.js.
 
Since the first release, A brand new version is released twice a month (on average), where every non-major version is backward compatible.
 
Official Site GitHib Documentation

Advantages

 
  • Focus on getting things done quickly. Sometimes this does not feel like an advantage
  • echnically very simple once you learn how to use it.
  • Embedded Jetty server
  • Lightweight and fast, especially compared to other counterparts here.
  • Lambda-based WebSocket API
  • Supports long-running async tasks with CompletableFuture
  • Real micro-framework
 

Limitations

 
  • Documentation is far from perfect. While suitable for someone with a prior Javalin knowledge; it simply not good enough for someone who just wants to learn from a scratch. I’m not joking, you are better using other 3rd party tutorials.
  • Not adhering to standard nomenclature. For example, what is usually known as Routes and Filters are combined together as Handlers. Which makes it harder when you read 3rd party tutorials and people keep referring to it as routes or filters.
  • Not mature enough; their feature to-do list is still way too long. To fight this you will need to rely on third-party dependencies and that is a very deep rabbit hole. Just the thought of managing and updating so many dependencies makes me shiver.
 

2. KTor

 
Introduction date: 2018 (1.0.0 version)
 
Ktor is the second framework on this list created for quickly creating web applications in Kotlin with minimal effort. It very light and do not impose any constraints on what underlying technology a project is going to use.
 
The thing that makes it stand up is that it’s produced by the Kotlin team. This is surprising as I find to be the least mature product here.
 
Official Site GitHib Documentation

Advantages

 
  • Surprisingly good documentation. I was so hard to say otherwise but I do not have any good argument. While not by-the-book, provided documentation looks more like a bunch of organized tutorials, and they work pretty well. This also includes great GitHub examples.
  • Reliable and stable
  • Small memory footprint and lightweight
  • Fast but competition is faster (like Javalin and http4d)
  • Perfect for prototyping
  • Real micro-framework
 

Limitations

 
  • Suffers from the same problem as Javalin and Spark. If you need to create anything complex you will need to lean on third-party libraries, and that’s a slippery slope.
  • If you do not know what are you doing then documentation is going to be confusing as hell.
  • Not mature enough
  • Small community
 

3. Spark

 
Introduction date: 2017 (1.0.0-alpha version)
 
Spark is the usual suspect when it comes to micro-services. It’s one of the oldest expressive Kotlin/Java web framework built for rapid development, you can even call it a granddaddy of Kotlin frameworks. Too bad the support is still in the alpha version.
 
Official Site GitHib Documentation

Advantages

 
  • Small memory footprint
  • Fast and lightweight
  • Excellent for rapid prototyping
  • Easy to setup
  • Plays well with Angular
  • Real micro-framework
  • Embedded Jetty server
 

Limitations

 
  • Kotlin support is in the alpha state since 2017. My advice, go with Spark only if you have previously used Spark for Java.
  • Documentation could be better, it is not intended for beginners.
  • Not suitable for large projects. Similar to Javalin. The moment you need to juggle third-party dependencies and updates everything starts falling apart. This is a subjective comment, so take it with a grain of salt.
 

4. Spring Boot

 
Introduction date: 2017 (Kotlin support)
 
Do not make me start. If you have never heard of Spring Boot you have been spending your time leaving under the rock. Love it or hate it, it’s here to stay.
 
Official Site GitHib Documentation

Advantages

 
  • Fast-ish
  • Easy to setup and handle
  • Spring family environment
  • Modular
  • Plays well with other libraries
  • Large community (very popular)
  • Enterprise-ready
 

Limitations

 
  • Large memory footprint. However, there’s a silver lining, memory is always cheaper compared to developers 🙂
  • Documentation fragmentation. Too many sources, too many versions, too many differences. Make sure you know which version you are going to use.
  • Braking changes between versions. If you hate what Angular is doing you will also hate it here.
  • Confusing documentation. While Java Spring Boot documentation is Top-notch, that is not the case with Kotlin. To make it even worse, official documentation is asking readers to look for support on sites like StackOverflow.
 

5. Vert.x

 
Introduction date: 2017 (3.4.0 version)
 
Vert.x is a tool-kit (ok-ish) for building reactive applications in a different programming language, like Java and Kotlin. I will just say one more thing. This tool(kit) is powerful, however, it is not for everyone. Keep reading and you will find why.
 
Official Site GitHib Documentation

Advantages

 
  • Fast
  • Small memory footprint – Comparable to Spark
  • WebSockets support
  • Solid documentation but chaotic. It’s perfect if you want to sit down and learn Vert.x, but God forbid you to want to find something specific.
  • Reactive systems approach. The idea is to have more flexible, loosely-coupled and scalable applications.
  • Vert.x offers a complete ecosystem
  • Highly modular
 

Limitations

 
  • Reactive manifesto – ha ha ha. Disclaimer: I support this initiative, but why call it a manifesto? When initiative sounds and feels so much better. It sounds a bit dirty.
  • It’s not for everybody. As a reactive toolkit, it fills a different niche compared to other frameworks here. For reference, other frameworks described here are imperative in nature. This is a very complex topic and you can find more about it here: Imperative vs Reactive.
  • Not a solution for you if the Spring Boot is your framework of choice. Before you try it make sure you know what are you getting into.
 

Conclusion

 
Just like with Java, this comparison is a fight between well-established all-around frameworks and their more lean micro-service counterparts. Which one will you use is up to you, I will not try to push my beliefs on you.
 
I will just tell you what I have selected in the end. As I have a prior Spring Boot experience choosing it was a no-brainer; practically there was nothing to chose as was already using it coupled with Java.
 
On the other hand, the real fight was between the other three micro-service frameworks. In the end, I went with Javalin. Two main reasons were: – Great documentation (My available time is limited, I do not want to waste it on lazily written documentation) – Fast prototyping (I need to be able to quickly create CRUD REST services)