Zo schrijf je pijnloos voor AWS in Kotlin zonder Java-erfenis

Ontwikkelaars die voor AWS in Kotlin hebben geschreven herinneren zich waarschijnlijk de Java SDK v2. Werken ermee in Kotlin-projecten is mogelijk, maar je moet voortdurend CompletableFuture in coroutines wrappen, je behelpen met lange Java-builder-syntaxis en onnodige afhankelijkheden naar je build slepen. Het AWS-team lost dit op met het officiële project aws-sdk-kotlin — een client die vanaf de basis specifiek voor Kotlin is geschreven.

Wat verandert er met de native Kotlin SDK

Het belangrijkste voordeel van de bibliotheek is native coroutine-ondersteuning en Kotlin Flow. Geen callback-spaghetti of async-wrappers. Aanroepen naar S3, DynamoDB of Lambda worden geschreven zoals elke andere async-code in Kotlin.

Het tweede belangrijke punt is de architecturale basis voor multiplatform. De bibliotheek richt zich op Kotlin Multiplatform en werkt out-of-the-box op meerdere doelplatformen:

• JVM voor klassieke backends op Ktor of Spring
• Android voor mobiele applicaties
• GraalVM Native Image voor snelle opstart van gecompileerde binaries

Codegeneratie via Smithy en gerichte build

AWS heeft honderden services. Als je clients voor elk van hen compileert en bundelt in één bibliotheek, wordt de grootte van het eindartefact belachelijk groot. De SDK-auteurs hebben dit opgelost door codegeneratie gebaseerd op de declaratieve taal Smithy.

De repository bevat geen voorgegenereerde code voor elke AWS-service. Code wordt aangemaakt tijdens het bouwen van het project. Als je de SDK zelf uit broncode bouwt, kun je alleen de services opgeven die je daadwerkelijk in je applicatie nodig hebt.

Configuratiefiltering vindt plaats in het local.properties-bestand:

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

Als je bepaalde services uit de build wilt verwijderen, gebruik je een minteken:

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

Het genereren van code wordt geactiveerd via Gradle:

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

Daarna wordt de gegenereerde module gebouwd met de standaardtaak:

./gradlew :services:lambda:build

Deze aanpak bespaart tijd tijdens lokale ontwikkeling en het testen van individuele SDK-modules.

Documentatiebuild via Dokka

Voor het documenteren van code gebruiken de ontwikkelaars Dokka — het standaard JetBrains-hulpmiddel dat werkt met het KDoc-formaat.

Om API-referentie lokaal te genereren, biedt de repository een commando:

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

De voltooide HTML-documentatie gaat naar de build/dokka/htmlMultiModule-directory. Om deze in een browser te openen, heb je een eenvoudige HTTP-server nodig, bijvoorbeeld de ingebouwde van IntelliJ IDEA of gestart via Python:

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

Is het de moeite waard om over te schakelen naar Kotlin SDK

De repository heeft ongeveer 500 sterren op GitHub. Het aantal is relatief klein omdat het project lange tijd in actieve ontwikkelingsstatus verkeerde en veel teams gewoontegetrouw Java SDK v2 gebruiken. Desondanks is de bibliotheek inmiddels productierijp en officieel ondersteund door Amazon.

De bibliotheek komt goed van pas in vier scenario's:

• Je bouwt een Android-app die directe toegang tot AWS-services nodig heeft zonder zware Java-afhankelijkheden mee te slepen.
• Je schrijft Serverless-functies in Kotlin voor AWS Lambda met GraalVM Native Image-compilatie, waarbij snelheid van koude start kritiek is.
• Je backend is volledig gebouwd op coroutines en Ktor, en je wilt een consistente async-codestijl behouden.
• Je maakt een multiplatform-module die logica combineert voor mobiel en server.

Als je al een groot legacy-project hebt op Spring Boot met de oude Java SDK, is er geen reden om dit haastig te herschrijven. Maar voor nieuwe services en applicaties in Kotlin ziet deze SDK eruit als de logische keuze.