俺のaws-sdk-goラッパーライブラリ3兄弟

去る2014年12月にStripeによるstripe/aws-goが公開され、 今年2015年1月にAWSがstripe/aws-goを拾い上げ、awslabs/aws-sdk-goとなり (ちなみにライセンスも元のMITからApacheライセンスになった)、そして その半年後の2015年6月にDeveloper Previewながらもついにaws/aws-sdk-goになりました。

前書きが長くなりましたが、ようやく自分のプロジェクトでもgoamzからaws-sdk-goへの移行を 完了させました。その過程で3つのラッパーライブラリを公開したので紹介します。

aws-go-sqs

https://github.com/nabeken/aws-go-sqs

これは以前書いたものです。stripe/aws-go自体に書いたものを 最新の状態へ追随させました。バッチ処理もちゃんと扱えるので便利だと思います。

aws-go-s3

https://github.com/nabeken/aws-go-s3

新作です。aws-go-sqsと同様にfunction optionパターンを適用し、リクエスト用の構造体を それっぽく操作できます。

http.Request.BodyをそのままS3にアップロードする際、SDKが io.ReadSeeker を 要求しているため、今のところ一時ファイルへ書き出してから改めてS3へアップロードする方法 しかありません(署名とかマルチパートアップロードのため?)。

aws-go-s3の今の実装では素朴に一旦 io.ReadAll したものを一時ファイルへ書き出し、それをSDKへ渡す 方式を採用しています。 今後の改善案としては、書き込みと読み出しを同時にできるようにしつつ、io.Seeker もいい感じに扱う ようにしたいところです。

aws-go-dynamodb

https://github.com/nabeken/aws-go-dynamodb

こちらも新作です。同じくfunction optionパターンでやってみました。

Expression APIを使うとクエリは文字列で表現できるようになったのでAPIクライアント的には楽になりました(意味不明なJSONを組み立てる必要がなくなった)。

DynamoDBで面倒なのはGoの構造体のmarshal, unmarshalです。 goamzではencoding/jsonを流用したmarshaler, unmarshalerがありましたが、 aws-sdk-goではdynamodbattributeパッケージがそれに該当します。

dynamodbattributeパッケージには一つ落とし穴があり、AttributeTypeにSet(StringSet/NumberSet/BinarySet)を使っている場合はこのパッケージでは正しく処理できません。これはオブジェクトがDocument TypeのListとMapで表現されているためです。移行時には注意する必要があります。

aws-go-dynamodbはitem.Unmarshalerインターフェースを用意し、それが実装されていればdynamodbattributeを使わずに このインターフェース経由でunmarshalするようにしています。 実装がなければ dynamodbattribute パッケージを使用します。

aws-sdk-go雑感