Many projects force their code to be formatted. We use spotless for this purpose. It can check for propper formatting, and also format the code for you. Then build pipeline checks if the code is properly formatted. Failing pipelines due to formatting errors are annoying and cost a lot of time and money. This blog proposes a solution.

When code evolves we usually deprecate old code. Sometimes we come across deprecations without any hints with what to replace it with. Kotlin has a solution for this by allowing you to specify a replace instruction.

For example, we created have an old REST client.

Spring boot supports a non-blocking programming model with the spring-webflux module. Webflux supports a Reactive API using the Reactor library Flux and Mono API types. This model forces you to write your code in a different style than most people are used to. It generally is much harder to follow and debug.

This post shows you a short example of using Kotlin’s Coroutines instead of Reactor to write your code in a more imperative and easier to follow style. It includes examples of using Retrofit as HTTP client to access external API’s concurrently in a non-blocking way.

At my current customer we use Github a lot. Everything requires a review via a Pull Request. It is sometimes tedious to switch from your IDE or terminal to the browser while creating a PR. Github has a command line utility called gh which you can use to automatically create a PR from the command line. It has lots of extra stuff as well, such as downloading releases, viewing issues, creating gists, cloning repo’s and code completion.

Start by following the installation steps in https://github.com/cli/cli to install the gh binary. There are packages for all operating systems.

This post gives an example how to read values and secrets from an alternative store instead of storing them in config files, which is never a good idea. The example uses the AWS parameter store, but can be easily adapted to the newer AWS Secrets Manager or any other store!

The goal is to avoid configuration files like these:

If you write lots of Kotlin code you might have noticed that it is annoying to write the named parameters when calling functions or when creating a new instance of class.

I found an IntelliJ IDEA plugin named 'Kotlin Fill Class' that does this for you. https://plugins.jetbrains.com/plugin/10942-kotlin-fill-class

SQL allows you to do calculations on columns over multiple rows using aggregate functions like COUNT, SUM, AVG etc. This post explains how to use them in Kotlin Exposed. We will also cover arithmetic operations on one or more columns. If you haven’t used Kotlin Exposed before, you can go here for an introduction.

Consider an application containing two tables in an SQL database: Comment and User. A comment is written by a user, and can receive likes/dislikes. The snippet below shows the table definitions:

This post explains how to use table aliases using Kotlin Exposed. Aliases are necessary when you want to join the same table multiple times. If you haven’t used Kotlin Exposed before, you can go here for an introduction: Kotlin Exposed - A lightweight SQL library.

In this example we have an application containing two tables: Message and User. The Message table has two references to the User table, one to model the 'fromUser' relationship and one for the 'toUser' relationship. The table definitions look as follows:

This is an overview of some optimization techniques used by Hotspot JVM to increase performance. I will start by giving a small example of how I ran into these optimizations while writing a naive benchmark. Each optimization is then explained with a short example and ends with some pointers on how to analyze your own code.

It’s quite common in a microservice style architecture to provide a type-safe client library that other services can use to communicate with your service. This can be package with a Retrofit client published to nexus by the maintainer of the service. Some projects might also generate that code from a OpenAPI spec or a gRPC proto file.

However, when we expose some of these APIs to the frontend, we lose the types. In this post I suggest a way to publish your backend API types as an NPM package. The frontend can then depend on these typings. Using typescript you now have compile time type safety and code completion. To see a sneak peak, scroll to the end :).

A big part of the fun of starting a new project is making a design and choosing an appropriate technology stack. If you are a Java developer and need to access a SQL database, a common choice is to use JPA with an ORM framework such as Hibernate. This adds a lot of complexity to your project for multiple reasons. In my experience, writing performing queries requires careful analysis. Writing custom queries is possible but more complex. For starters, JPQL/HQL queries are parsed at runtime and the criteria API is far from user friendly. Moreover, the extensive use of annotations makes it harder to quickly see how the database is structured.

Kotlin Exposed is a lightweight SQL library on top of JDBC that could serve as a good alternative. When using Kotlin Exposed you start by describing your database structure using plain Kotlin code. The code resembles SQL DDL statements very closely and does not require any annotations or reflection! You can use these descriptions to write type safe queries. These queries can be written in two flavors: DSL and/or DAO. This post focuses on the DSL flavor.

When building a service in gRPC you define the message and service definition in a .proto file. gRPC generates client, server and DTO implementations automatically for you in multiple languages. At the end of this post you will understand how to make your gRPC API also accessible via HTTP JSON by using Envoy as a transcoding proxy. You can test it out yourself by running the Java code in the attached github repo. For a quick introduction on gRPC itself, please read gRPC as an alternative to REST.