Come scrivere per AWS in Kotlin senza dolore e legacy Java

Gli sviluppatori che hanno scritto per AWS in Kotlin probabilmente ricordano Java SDK v2. Lavorare con esso nei progetti Kotlin è possibile, ma devi costantemente avvolgere CompletableFuture in coroutine, sopportare la lunga sintassi Java-builder e trascinare dipendenze extra nella build. Il team AWS risolve questo con un progetto ufficiale aws-sdk-kotlin — un client scritto da zero specificamente per Kotlin.

Cosa cambia con l'SDK Kotlin nativo

Il principale vantaggio della libreria è il supporto nativo delle coroutine e Kotlin Flow. Niente più callback spaghetti o wrapper asincroni. Le chiamate a S3, DynamoDB o Lambda sono scritte esattamente come qualsiasi altro codice asincrono in Kotlin.

Il secondo punto importante è l'architettura multipla della libreria. La libreria si rivolge a Kotlin Multiplatform e funziona out of the box su più piattaforme target:

• JVM per backend classici su Ktor o Spring
• Android per applicazioni mobili
• GraalVM Native Image per avvio rapido di binari compilati

Generazione del codice tramite Smithy e build mirata

AWS ha centinaia di servizi. Se compili e impacchetti i client per ciascuno di essi in un'unica libreria, la dimensione dell'artefatto finale diventa enorme. Gli autori dell'SDK hanno risolto questo attraverso la generazione del codice basata sul linguaggio dichiarativo Smithy.

Il repository non contiene codice pre-generato per ogni servizio AWS. Il codice viene creato durante la build del progetto. Se compili l'SDK da sorgente, puoi specificare solo i servizi effettivamente necessari nella tua applicazione.

Il filtraggio della configurazione avviene nel file local.properties:

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

Se hai bisogno di rimuovere certi servizi dalla build, usa un segno meno:

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

La generazione del codice viene attivata tramite Gradle:

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

Dopo di ciò, il modulo generato viene costruito con il task standard:

./gradlew :services:lambda:build

Questo approccio fa risparmiare tempo durante lo sviluppo locale e il test dei singoli moduli SDK.

Build della documentazione tramite Dokka

Per documentare il codice, gli sviluppatori usano Dokka — lo strumento standard di JetBrains che funziona con il formato KDoc.

Per generare la reference API localmente, il repository fornisce un comando:

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

La documentazione HTML finita va nella directory build/dokka/htmlMultiModule. Per aprirla nel browser, ti serve un qualsiasi semplice server HTTP, per esempio quello integrato in IntelliJ IDEA o lanciato tramite Python:

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

Vale la pena passare a Kotlin SDK

Il repository ha circa 500 stelle su GitHub. Il numero è relativamente piccolo perché il progetto è stato a lungo in stato di sviluppo attivo, e molti team usano abitualmente Java SDK v2. Tuttavia, la libreria è già production-ready e ufficialmente supportata da Amazon.

La libreria torna utile in quattro scenari:

• Stai costruendo un'app Android che ha bisogno di accesso diretto ai servizi AWS senza trascinare dipendenze Java pesanti.
• Stai scrivendo funzioni Serverless in Kotlin per AWS Lambda con compilazione GraalVM Native Image, dove la velocità di cold start è critica.
• Il tuo backend è interamente costruito su coroutine e Ktor, e vuoi mantenere uno stile di codice asincrono coerente.
• Stai realizzando un modulo multiplatform che combina logica per mobile e server.

Se hai già un grande progetto legacy su Spring Boot con il vecchio Java SDK, non c'è motivo di riscriverlo urgentemente. Ma per nuovi servizi e applicazioni in Kotlin, questo SDK sembra la scelta logica.