Как писать под AWS на Kotlin без боли и Java-наследия
Разработчики, писавшие под AWS на Kotlin, наверняка помнят Java SDK v2. Работать с ним в Kotlin-проектах можно, но приходится постоянно оборачивать CompletableFuture в корутины, мириться с длинным синтаксисом Java-билдеров и тащить в сборку лишние зависимости. Команда AWS решает эту проблему официальным проектом aws-sdk-kotlin — клиентом, написанным с нуля специально под Kotlin.
Что меняется с нативным Kotlin SDK
Главный плюс библиотеки — нативная поддержка корутин и Kotlin Flow. Никаких вермишелей из колбэков и асинхронных оберток. Вызовы S3, DynamoDB или Lambda пишутся ровно так же, как и любой другой асинхронный код на Kotlin.
Второй важный момент — архитектурный задел под мультиплатформенность. Библиотека ориентирована на Kotlin Multiplatform и из коробки работает на нескольких целевых платформах:
- JVM для классических бэкендов на Ktor или Spring
- Android для мобильных приложений
- GraalVM Native Image для быстрого старта компилированных бинарников
Генерация кода через Smithy и точечная сборка
AWS насчитывает сотни сервисов. Если скомпилировать и упаковать клиенты для каждого из них в одну библиотеку, размер итогового артефакта станет неприлично большим. Авторы SDK решили эту задачу через кодогенерацию на базе декларативного языка Smithy.
В репозитории нет готового сгенерированного кода под каждый сервис AWS. Код создается при сборке проекта. Если вы собираете SDK самостоятельно из исходников, можно указать только те сервисы, которые реально нужны в приложении.
Настройка фильтрации происходит в файле local.properties:
# Генерируем клиент только для AWS Lambda
aws.services=+lambda
Если требуется убрать определенные сервисы из сборки, используется знак минус:
# Исключаем AWS Location и DynamoDB
aws.services=-location,-dynamodb
Генерация кода запускается через Gradle:
./gradlew --no-daemon :codegen:sdk:bootstrap
После этого сгенерированный модуль собирается стандартной таской:
./gradlew :services:lambda:build
такой подход экономит время при локальной разработке и тестировании отдельных модулей SDK.
Сборка документации через Dokka
Для документирования кода разработчики задействовали Dokka — стандартный инструмент от JetBrains, работающий с форматом KDoc.
Чтобы сгенерировать API-справку локально, в репозитории предусмотрена команда:
./gradlew --no-daemon --no-parallel dokkaHtmlMultiModule
Готовая HTML-документация складывается в директорию build/dokka/htmlMultiModule. Чтобы открыть её в браузере, понадобится любой простой HTTP-сервер, например встроенный в IntelliJ IDEA или запущенный через Python:
python3 -m http.server --directory build/dokka/htmlMultiModule
Стоит ли переходить на Kotlin SDK
У репозитория около 500 звезд на GitHub. Число относительно небольшое, потому что проект долго находился в статусе активной разработки, а многие команды по привычке используют Java SDK v2. Тем не менее, библиотека уже готова к продакшену и официально поддерживается Amazon.
Библиотека пригодится в четырех сценариях:
- Вы создаете Android-приложение, которому нужен прямой доступ к сервисам AWS без тащения тяжелых Java-зависимостей.
- Вы пишете Serverless-функции на Kotlin для AWS Lambda с компиляцией в GraalVM Native Image, где критически важна скорость холодного старта.
- Ваш бэкенд полностью построен на корутинах и Ktor, и хочется сохранить единый стиль асинхронного кода.
- Вы делаете мультиплатформенный модуль, объединяющий логику для мобилок и сервера.
Если у вас уже работает большой legacy-проект на Spring Boot со старым Java SDK, экстренно переписывать его смысла нет. Но для новых сервисов и приложений на Kotlin этот SDK выглядит логичным выбором.
