Cómo programar para AWS en Kotlin sin dolor ni legado de Java

Los desarrolladores que programaron para AWS en Kotlin probablemente recuerdan el Java SDK v2. Trabajar con él en proyectos Kotlin es posible, pero constantemente tienes que envolver CompletableFuture en corrutinas, soportar la larga sintaxis de constructores de Java y arrastrar dependencias extra a la compilación. El equipo de AWS resuelve esto con un proyecto oficial aws-sdk-kotlin — un cliente escrito desde cero específicamente para Kotlin.

Qué cambia con el SDK Kotlin nativo

La principal ventaja de la biblioteca es el soporte nativo de corrutinas y Kotlin Flow. No más spaghetti de callbacks ni envoltorios async. Las llamadas a S3, DynamoDB o Lambda se escriben exactamente como cualquier otro código async en Kotlin.

El segundo punto importante es la base arquitectónica para multiplatform. La biblioteca está orientada a Kotlin Multiplatform y funciona de inmediato en múltiples plataformas objetivo:

• JVM para backends clásicos en Ktor o Spring
• Android para aplicaciones móviles
• GraalVM Native Image para inicio rápido de binarios compilados

Generación de código mediante Smithy y compilación dirigida

AWS tiene cientos de servicios. Si compilas y empaquetas clientes para cada uno de ellos en una sola biblioteca, el tamaño del artefacto final se vuelve ridículamente grande. Los autores del SDK resolvieron esto mediante la generación de código basada en el lenguaje declarativo Smithy.

El repositorio no contiene código pre-generado para cada servicio de AWS. El código se crea durante la compilación del proyecto. Si compilas el SDK tú mismo desde el código fuente, puedes especificar solo los servicios que realmente necesitas en tu aplicación.

El filtrado de configuración ocurre en el archivo local.properties:

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

Si necesitas eliminar ciertos servicios de la compilación, usa un signo menos:

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

La generación de código se activa a través de Gradle:

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

Después de eso, el módulo generado se compila con la tarea estándar:

./gradlew :services:lambda:build

Este enfoque ahorra tiempo durante el desarrollo local y las pruebas de módulos individuales del SDK.

Compilación de documentación mediante Dokka

Para documentar el código, los desarrolladores usan Dokka — la herramienta estándar de JetBrains que funciona con el formato KDoc.

Para generar la referencia de API localmente, el repositorio proporciona un comando:

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

La documentación HTML terminada va al directorio build/dokka/htmlMultiModule. Para abrirla en el navegador, necesitas cualquier servidor HTTP simple, por ejemplo el integrado en IntelliJ IDEA o lanzado mediante Python:

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

¿Vale la pena cambiar al Kotlin SDK

El repositorio tiene alrededor de 500 estrellas en GitHub. El número es relativamente pequeño porque el proyecto estuvo en estado de desarrollo activo durante mucho tiempo, y muchos equipos usan por costumbre el Java SDK v2. Sin embargo, la biblioteca ya está lista para producción y está oficialmente soportada por Amazon.

La biblioteca resulta útil en cuatro escenarios:

• Estás construyendo una aplicación Android que necesita acceso directo a servicios AWS sin arrastrar dependencias Java pesadas.
• Estás escribiendo funciones Serverless en Kotlin para AWS Lambda con compilación GraalVM Native Image, donde la velocidad de inicio en frío es crítica.
• Tu backend está completamente construido sobre corrutinas y Ktor, y quieres mantener un estilo de código async consistente.
• Estás haciendo un módulo multiplatform que combina lógica para móvil y servidor.

Si ya tienes un proyecto legacy grande en Spring Boot con el antiguo Java SDK, no tiene sentido reescribirlo urgentemente. Pero para nuevos servicios y aplicaciones en Kotlin, este SDK parece la elección lógica.