Wie man für AWS in Kotlin schreibt – ohne Schmerzen und Java-Legacy

Entwickler, die für AWS in Kotlin geschrieben haben, erinnern sich wahrscheinlich an das Java SDK v2. Es ist zwar möglich, damit in Kotlin-Projekten zu arbeiten, aber man muss ständig CompletableFuture in Coroutinen wrappen, sich mit langer Java-Builder-Syntax herumschlagen und zusätzliche Abhängigkeiten in den Build schleppen. Das AWS-Team löst dies mit einem offiziellen Projekt aws-sdk-kotlin — einem Client, der von Grund auf speziell für Kotlin geschrieben wurde.

Was ändert sich mit dem nativen Kotlin SDK

Der Hauptvorteil der Bibliothek ist die native Coroutinen-Unterstützung und Kotlin Flow. Kein Callback-Spagetti oder async-Wrapper. Aufrufe an S3, DynamoDB oder Lambda werden genau wie jeder andere asynchrone Code in Kotlin geschrieben.

Der zweite wichtige Punkt ist die architektonische Grundlage für Multiplatform. Die Bibliothek zielt auf Kotlin Multiplatform ab und funktioniert out of the box auf mehreren Zielplattformen:

• JVM für klassische Backends auf Ktor oder Spring
• Android für mobile Anwendungen
• GraalVM Native Image für schnellen Startup von kompilierten Binärdateien

Codegenerierung über Smithy und gezielter Build

AWS hat Hunderte von Services. Wenn man Clients für jeden davon kompiliert und in eine einzige Bibliothek packt, wird die Größe des finalen Artefakts lächerlich groß. Die SDK-Autoren haben dies durch Codegenerierung basierend auf der deklarativen Smithy-Sprache gelöst.

Das Repository enthält keinen vorgefertigten Code für jeden AWS-Service. Code wird während des Projekt-Builds erstellt. Wenn man das SDK selbst aus dem Quellcode erstellt, kann man nur die Services angeben, die tatsächlich in der Anwendung benötigt werden.

Die Konfigurationsfilterung erfolgt in der local.properties-Datei:

# Генерируем клиент только для AWS Lambda
aws.services=+lambda

Wenn man bestimmte Services aus dem Build entfernen möchte, verwendet man ein Minuszeichen:

# Исключаем AWS Location и DynamoDB
aws.services=-location,-dynamodb

Die Codegenerierung wird über Gradle angestoßen:

./gradlew --no-daemon :codegen:sdk:bootstrap

Danach wird das generierte Modul mit der Standard-Task gebaut:

./gradlew :services:lambda:build

Dieser Ansatz spart Zeit bei lokaler Entwicklung und beim Testen einzelner SDK-Module.

Dokumentations-Build über Dokka

Für die Dokumentation von Code verwenden die Entwickler Dokka — das Standard-Tool von JetBrains, das mit dem KDoc-Format arbeitet.

Um die API-Referenz lokal zu generieren, stellt das Repository einen Befehl bereit:

./gradlew --no-daemon --no-parallel dokkaHtmlMultiModule

Die fertige HTML-Dokumentation geht in das build/dokka/htmlMultiModule-Verzeichnis. Um sie im Browser zu öffnen, braucht man einen einfachen HTTP-Server, zum Beispiel den in IntelliJ IDEA eingebauten oder einen über Python gestarteten:

python3 -m http.server --directory build/dokka/htmlMultiModule

Lohnt sich der Umstieg auf Kotlin SDK

Das Repository hat etwa 500 Sterne auf GitHub. Die Zahl ist relativ gering, weil das Projekt lange Zeit im Status aktiver Entwicklung war und viele Teams gewohnheitsmäßig das Java SDK v2 verwenden. Nichtsdestotrotz ist die Bibliothek bereits produktionsreif und wird offiziell von Amazon unterstützt.

Die Bibliothek ist in vier Szenarien nützlich:

• Man baut eine Android-App, die direkten Zugriff auf AWS-Services benötigt, ohne schwere Java-Abhängigkeiten mitzuschleppen.
• Man schreibt Serverless-Funktionen in Kotlin für AWS Lambda mit GraalVM Native Image-Kompilierung, wo die Cold-Start-Geschwindigkeit kritisch ist.
• Das Backend ist vollständig auf Coroutinen und Ktor aufgebaut und man möchte einen konsistenten asynchronen Codestil beibehalten.
• Man erstellt ein Multiplatform-Modul, das Logik für Mobile und Server kombiniert.

Wenn man bereits ein großes Legacy-Projekt auf Spring Boot mit dem alten Java SDK hat, gibt es keinen Sinn darin, es dringend umzuschreiben. Aber für neue Services und Anwendungen in Kotlin sieht dieses SDK nach der logischen Wahl aus.