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.

The logger example

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:

• An opinionated Kotlin backend service — Framework
• An opinionated Kotlin backend service — Build & Deployment

API Routing and documentation

Ktor Routing

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:

routing…

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…

TL;DR;

This article series explains the scaffolding for Kotlin / Ktor based backend services. It elaborates on the following topics:

• An opinionated Kotlin backend service - Framework
• An opinionated Kotlin backend service - Build & Deployment
• An opinionated Kotlin backend service - API Routing and Documentation
  + OpenAPI Generation with Ktor
  + Object validation in Ktor/Kotlin
  + JSON Serialization in Ktor
• An opinionated Kotlin backend service - Database / Migration / ORM
• An opinionated Kotlin backend service - Testing

Quick start

• clone the repo
• cd into Ktor-Template
• run docker-compose up (or sudo docker-compose up)
• Open http://localhost:2000

You should see the OpenAPI documentation:

Introduction

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

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…

Introduction

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

According to https://ktor.io/docs/serialization.html 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(…

Introduction

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: http://java-source.net/open-source/validation).

What I didn’t want (https://sebthom.github.io/oval):

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

More to my liking (https://joi.dev), …

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…