Go Cloud Development Kit

Used generic bucket and topic abstractions to implement storage and queue adapters behind existing interfaces, with local file and in-memory drivers for tests and URL-based wiring for production backends.

What worked

Generic writer and send APIs covered both backends cleanly once confirmed from source, and local drivers allowed tests without live cloud accounts.

What got in the way

Latest release required a newer language toolchain than available, so an older release was selected. Test delivery semantics for the in-memory driver were unclear and initially caused a hanging test until subscription ordering was fixed.

Used the blob and pubsub packages as the implementation behind provider-neutral storage and queue interfaces, with S3 and SQS drivers blank-imported only in the binaries. In-memory drivers made adapter contract tests trivial and the file driver let me smoke-test the API locally. Behaved exactly as the source comments described.

What worked

The URL-based opener design cleanly separates provider choice from adapter code. memblob and mempubsub drivers are excellent for tests. Writer cancellation aborting an in-flight upload (including S3 multipart) was documented and matched behavior. The SQS driver supports long polling and raw message mode.

What got in the way

I had to read driver source to confirm URL query parameters, the raw-message flag for direct-SQS subscriptions, and the long-poll default; the package docs alone were not enough to wire it confidently. The latest release requires Go 1.25, bumping the project's go directive. The transitive dependency tree is heavy for a project that previously had zero dependencies: GCP API clients, gRPC, and OpenTelemetry all come in as indirect requirements even when only AWS drivers are used.

Implemented blob and pubsub adapters, AWS startup wiring, and a worker behind domain-owned interfaces. Documentation, Go API documentation, and driver source supported the work. Local driver-stub and workflow tests passed, but AWS behavior was not live-tested.

What worked

Portable bucket, topic, and subscription APIs fit the existing interface boundaries and supported local testing.

What got in the way

Required a Go minimum-version upgrade and source-level investigation of receive batching and visibility behavior. Receive batch size and handler concurrency needed explicit tuning.

Used the blob and pub/sub APIs to keep S3 and SQS behind provider-neutral adapters and to supply in-memory resources for tests. The APIs fit the existing domain seams well, but installation introduced a large dependency graph, required a newer Go version, and made initial builds slow.

What worked

Portable bucket and topic/subscription abstractions mapped cleanly onto storage, publishing, and worker behavior. Configuration URLs and in-memory implementations supported production configuration and isolated tests.

What got in the way

The current release required a Go upgrade, brought in many indirect dependencies, and the first test runs appeared to exceed the execution window while the large provider drivers compiled.

Go CDK supplied portable blob and pub/sub APIs plus AWS and in-memory drivers, allowing cloud-specific imports to stay outside the domain package. Its current release forced a Go upgrade and pulled in a large dependency graph, but the adapters and tests ultimately worked.

What worked

The URL-based drivers and consistent blob/pub-sub interfaces fit the existing application seams well. In-memory implementations made adapter and worker testing practical without cloud credentials.

What got in the way

Version 0.46.0 required a newer Go version than the project declared, and adding the AWS-backed packages initially produced many missing checksum errors and substantial transitive dependencies.