In every language a "dedicated" engineer can write code that is hard to read and harder to maintain, Kotlin is no exception. It seems unfair to use badly written code to make the point that Kotlin has a consistency problem (not sure what that means really) and also a readability and safety problem but let's go through the examples.

If you're trying to replace some of the Java code by Kotlin code, don't start with the low-level classes but the high-level modules. …

This is the third part of my series on Kotlin based backend services.
If you missed the first two parts:

API Routing and documentation

Defining routes in Ktor is simple and very concise due to the DSL. To define a route, call the routing function and add the routes you need:

routing {
// here go your routes

Using different http methods:

routing {     
get("/customer/{id}") { /* handler */ }
post("/customer") { /* handler */ }
put("/customer/{id}") { /* handler */ }

Grouped by path:


This is the second part of my series on Kotlin based backend services.
If you missed the first part: An opinionated Kotlin backend service — Framework.

Gradle Build

I had four main requirements for the build system:

  1. I wanted to use Gradle (not Maven)
  2. Use a single language for code, configuration, build and deployment (as much as possible)
  3. I wanted to manage plugin and dependency versions centrally
  4. I wanted to support a mono repo approach with each backend service being a separate Gradle module

Using Kotlin instead of Groovy supports the goal of using a single language for everything.

There are two…


As part of my series “An opinionated Kotlin backend service”, I was researching ways to generate OpenAPI documentation automatically (the problem). Before explaining how to generate api documentation from code (the solution), I will give a short overview of different approaches to generating such documentation.


OpenAPI is the standard to describe APIs since the developers of RAML joined the OpenAPI Initiative (it’s a bit more complicated but this isn’t an article about the different standards…). If you want your backend service to be consumed properly it should have an OpenAPI documentation.

I already have an API

If you already have an API and only need…


As part of my series “An opinionated Kotlin backend service”, I was checking out different ways to serialize/deserialize JSON payloads.

According to these are the supported converters:

  1. Gson
  2. Jackson
  3. kotlinx.serialization

I tested #1 and #3 and because I like challenges from time to time I threw Moshi into the mix. I left out Jackson because… well why not ;-).

My test was simple. I wanted to serialize/deserialize this data structure(s):

data class Customer(
var customerUUID: String,
var createdAt: Instant,
var modified: Instant,
var firstName: String,
var lastName: String,
var language: Language,
var account: Account,
data class Account(…


As part of my series An opinionated Kotlin backend service, I was checking out several libraries to validate client requests.

My requirement was to use a Kotlin library to have a concise and fluent API without the typical Java verbosity (thus none of these made it onto my list:

What I didn’t want (

public class BusinessObject {   @NotNull
private String name;
private String deliveryAddress;
private String invoiceAddress;
@Assert(expr = "_value ==_this.deliveryAddress || _value == _
this.invoiceAddress", lang = "groovy")
public String mailingAddress;

More to my liking (, …

I agree with Joost Klitsie, the author is holding it wrong ;-). Scope functions are very useful if used properly. Showing bad examples of scope usage and then deducing that scopes make your code less readable is a logical fallacy.

The deleteImage is such a bad example. As Joost already demonstrated, there are better ways to write that code without falling back to the terrible Java like null check. My favorite is:

val imageFile = getImage() ?: return

But this would do nicely too (no scope):

if (imageFile?.exists() == true) imageFile?.delete()

Even using run is better than the Java style…


There are many ways to build, test, deploy and publish an Android app.

You can do it manually.
It’s not hard or time-consuming to create a signed APK or Bundle in Android Studio, upload it to Google Play and promote it through the different testing tracks up to production. I did it for many years. I thought the time automation saves won’t compensate for the effort to set up a working pipeline. I was wrong. Automation doesn’t just save time, it also makes the process more reliable, less error-prone (to human error) and encourages to deploy/publish more often. In general the…

Emanuel Moecklin

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store