Kotlin and Jooby in the backend

Quick, simple, fun and type-safe backend web development

Presenting at Socrates Day Berlin. Picture in the background by @dmitrykandalov

On the weekend, I participated at the first SoCraTes Day Berlin, a very well organized event by my good friend Raimo Radzcewski @rradzcewski and the Softwerkskammer Berlin. I met old friends, got to meet great new people and learned a couple of things over the day, not least how to make sourdough bread. I also held a session, on my recent experience building a backend service with Kotlin and the Jooby Framework, with some slides created at 2am in the morning:

Context

In this recent project, we had been in the fortunate situation to have been given almost complete autonomy over which language, framework and infrastructure to use. The only strong requirement that I actually recall, in that regard, has been that the backend service needs to run on the JVM.

Why Kotlin

The three years before I joined flinc, I have developed almost exclusively on Scala and the Play! Framework, and had little experience in the more traditional Java web development ways like JEE or Spring.

What I liked about Scala in the past has been the concise and expressive code it allows me to write. On the other hand I had encountered fairly long compilation times in bigger projects, which made TDD feel very sluggish.

Also, once in a while, I coded myself into situations where the Scala type-system and compiler have no longer been on my side and needed a couple of hours persuasion to calm down. Lastly I remember more than a few heated discussions, on which of the several possible ways to write lambdas and how to format Scala code is “the right one”.

Coming back to Java 8 from Scala has been a bit of a shocker as well. There is so much useless cruft that is cluttering up a typical code base and adding complication. A lot of the APIs feel quite dated and in general it feels like the language has not aged well.

Kotlin has been high on my list of languages to try out (up there with Elixir), offering complete interoperability with Java. From the looks of it, the language designers seemed to take the best cues from other languages to create a more approachable Scala for the JVM. Since the language has been developed at JetBrains, the makers of IntelliJ IDEA, it comes with amazing IDE support as well (Refactorings!).

Highest on the list of features in Kotlin compared to Java, for me, have been, type inference, immutable data classes, String interpolation, a sane Collections API, extension functions, improved control flow primitives like when-expressions, and much more. Have a look at the excellent Kotlin docs.

Kotlin often has surprisingly simple solutions to common problems.

So after three months of writing code for the backend in Kotlin, I can say this: I enjoyed it immensely. If you are currently writing Java you should at least try out Kotlin in some pet project.

Jooby

The other major technical decision we had to make at the beginning of the project has been which web-framework to use. In many projects, this decision is already done, either because a company or team has always used a certain framework, or the client requires a specific framework to be used. As it turned out, my previous experience with Play! is not that useful when Scala is removed from the equation and since we had been given full autonomy we decided to have another look around.

In the spare time between switching jobs, I tried out several different web-frameworks for the JVM, including Grails, Spring (Spring-Boot), SparkJava, Dropwizard, Jooby and others. What I found was, that I take a framework in which I tend to write explicit code and a little more boilerplate, over the convention-over-configuration magic of something like Spring any day of the week.

What I wanted was a framework on top of a modern server like Netty or Undertow and preferably one that follows the approach of seeing the server as a function. Since Kotlin is fully interoperable with Java, the framework did not necessarily had to explicitly support Kotlin, but looking at the different options I found that the ones that have Kotlin support actually feel much more natural.

It was also important to me, that the API layer and other parts that are tightly coupled with the framework are still simple to test in isolation. Something that was not so in various options we had considered.

Jooby ticked almost all our boxes. It’s design is simple and the layer on top of Netty is quite thin. It is also easy to change or add functionality by registering functions as handlers at various extension points.

In the simplest form, a Jooby App basically brings a server with the request handling DSL on top, but it offers loads of optional modules to turn it into a full-stack web framework, complete with asset pipeline, template rendering, data access, caching, security, what have you. It is also easy to write your own module, which we have done fairly early during our project.

We ended up using Jooby with the modules for Jackson, Hibernate Validator, JDBI, FlywayDB and Quartz as well as the Metrics module. Some but not all of the typical quirks that come with using libraries like Jackson, JDBI and Hibernate Validator in Java 8 are mitigated by the respective Jooby modules. Some things like having to configure Jackson and bad i18n in Hibernate Validator and so on still existed, but we could easily configure and modify the default behavior through the extension points that Jooby provides.

What I liked especially about Jooby has been the ease of testing the API-layer, complete with JSON (de-)serialization, security filters, routing, and so on. We only made sure that all interactions between our controllers and the domain model went through a layer of services and repositories and we used a JUnit rule to create a Jooby instance with the domain mocked during the API layer tests. The result have been very fast API unit tests. Testing a Jooby app is also well documented.

Finally a word or two of warning: The backend service we developed has not yet been put under a lot of stress. We encountered a configuration issue in our staging environment early on, because the number of threads used by Netty and Jooby are derived from the number of cores of the machine it is running on. Since we are running the service in a container, we had to manually set the maximum number of allowed threads (Update: This has since been fixed #916). So your mileage may vary. Make sure to use the provided Metrics module and closely monitor your Jooby app.

Lastly, Jooby is an open-source project written by Edgar Espina who I came to know as a helpful, nice and approachable guy. There is no Enterprise support for Jooby at the moment, but I don’t see this as an issue since it relies a lot on battle-tested libraries underneath the comparably thin layer of framework code. If you do decide to use Jooby in your product or projects, do let him know on Twitter or Gitter and contribute, if you can.

Happy coding!

Kudos to Marc Reichelt for leaving his trusted Android environment behind for a while to join me in the backend during this project.