Como Desenvolver para AWS em Kotlin Sem Dor e Legado Java

Desenvolvedores que escreveram para AWS em Kotlin provavelmente se lembram do Java SDK v2. Trabalhar com ele em projetos Kotlin é possível, mas você constantemente precisa envolver CompletableFuture em coroutines, lidar com a longa sintaxe de builder do Java e arrastar dependências extras para o build. A equipe da AWS resolve isso com um projeto oficial aws-sdk-kotlin — um cliente escrito do zero especificamente para Kotlin.

O que muda com o SDK Kotlin nativo

A principal vantagem da biblioteca é o suporte nativo a coroutines e Kotlin Flow. Sem callback spaghetti ou wrappers de async. Chamadas para S3, DynamoDB ou Lambda são escritas exatamente como qualquer outro código assíncrono em Kotlin.

O segundo ponto importante é a base arquitetural para multiplatform. A biblioteca é direcionada para Kotlin Multiplatform e funciona prontamente em múltiplas plataformas-alvo:

• JVM para backends clássicos em Ktor ou Spring
• Android para aplicações móveis
• GraalVM Native Image para inicialização rápida de binários compilados

Geração de código via Smithy e build direcionado

A AWS tem centenas de serviços. Se você compilar e empacotar clientes para cada um deles em uma única biblioteca, o tamanho do artefato final se torna absurdamente grande. Os autores do SDK resolveram isso através de geração de código baseada na linguagem declarativa Smithy.

O repositório não contém código pré-gerado para cada serviço da AWS. O código é criado durante o build do projeto. Se você compilar o SDK você mesmo a partir do código-fonte, pode especificar apenas os serviços realmente necessários na sua aplicação.

O filtro de configuração acontece no arquivo local.properties:

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

Se você precisa remover certos serviços do build, use um sinal de menos:

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

A geração de código é acionada através do Gradle:

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

Depois disso, o módulo gerado é compilado com a tarefa padrão:

./gradlew :services:lambda:build

Essa abordagem economiza tempo durante o desenvolvimento local e teste de módulos individuais do SDK.

Build de documentação via Dokka

Para documentar o código, os desenvolvedores usam Dokka — a ferramenta padrão da JetBrains que funciona com o formato KDoc.

Para gerar a referência da API localmente, o repositório fornece um comando:

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

A documentação HTML finalizada vai para o diretório build/dokka/htmlMultiModule. Para abrir no navegador, você precisa de qualquer servidor HTTP simples, por exemplo o embutido no IntelliJ IDEA ou lançado via Python:

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

Vale a pena migrar para o Kotlin SDK

O repositório tem cerca de 500 estrelas no GitHub. O número é relativamente pequeno porque o projeto estava em status de desenvolvimento ativo por muito tempo, e muitas equipes usam o Java SDK v2 por hábito. Mesmo assim, a biblioteca já está pronta para produção e é oficialmente suportada pela Amazon.

A biblioteca é útil em quatro cenários:

• Você está construindo um aplicativo Android que precisa de acesso direto aos serviços AWS sem arrastar dependências Java pesadas.
• Você está escrevendo funções Serverless em Kotlin para AWS Lambda com compilação GraalVM Native Image, onde a velocidade de cold start é crítica.
• Seu backend é inteiramente construído em coroutines e Ktor, e você quer manter um estilo de código assíncrono consistente.
• Você está fazendo um módulo multiplatform que combina lógica para mobile e servidor.

Se você já tem um grande projeto legado em Spring Boot com o antigo Java SDK, não faz sentido reescrevê-lo com urgência. Mas para novos serviços e aplicações em Kotlin, esse SDK parece ser a escolha lógica.