Skip to content
AWS docs1.0

Ktor Service Coverage Examples

Latest stable Based on AWS release 1.0.0

A runnable 1.0.0 example for the remaining AWS service plugins.

Exercise SES/v2, SNS, CloudWatch, CloudWatch Logs, Kinesis, and STS through one small Ktor application surface.

Use it when validating plugin installation and request/response mapping without depending on uneven emulator coverage.

This example is not published. Run ./gradlew :aws-ktor-service-coverage-examples:test from the release source.

Each plugin receives an application-owned operation facade. Routes call the same application accessors used by production integrations.

  1. Provide the six operation facades.
  2. Install serviceCoverageExampleModule.
  3. Call the /coverage/* routes.
  4. Verify the mapped AWS requests and JSON responses.

ServiceCoverageExampleRoutes.kt exposes email, notification, metric, log, stream-record, and caller-identity routes.

Start with STS, then add one write-oriented service at a time so configuration and mapping failures remain isolated.

The host application owns AWS clients, endpoints, credentials, and operation facades. Ktor owns only plugin installation and routing.

Set the CloudWatch namespace, log group and stream, Kinesis stream name, and SNS topic ARN through ServiceCoverageExampleOptions.

Blank request fields fail validation. Missing resources, credentials, endpoint support, or IAM permissions surface through the injected operations.

Use the repository’s Floci-first policy where the API is supported, LocalStack for explicit gaps, or real AWS endpoints owned by the application.

ServiceCoverageExampleRoutesTest uses MockK facades to verify plugin accessors, JSON mapping, AWS request mapping, and response mapping deterministically.

Continue with the dedicated S3, SQS, DynamoDB, and Exposed examples for deeper lifecycle and persistence scenarios.

The example does not prove emulator parity, live AWS permissions, retry policy, production observability, or resource provisioning.