俺の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雑感
- 1年も掛からずに一気に整備された。AWSの本気を感じた。
- APIのアップデートがあってもすぐに使用可能になってよい
- 各サービスのパッケージにはそれぞれAPI部分のインターフェースが自動生成されているのでそれを使うことでテスト時にモックへ差し替えられる
- このライブラリはプリミティブなものなのでやはりラッパーは自分で書く必要がある