エンジニアの鈴木(Kentaro SUZUKI (@szk3) | Twitter)です。
Amazon.com CTO Werner Vogels が登壇するKeynoteでは、Serverless関連の大型アップデート・新サービスが大量に発表されました。 Wernerの動画はコンテンツも良いのですが、AWS CEO のAndyと同様にプレゼンの勉強になるのでオススメです！
どうしても派手なアップデートに目が行きがちな re:Invent ですが、 各会場で行われるセッションでは、re:Invent前に発表された地味だけど嬉しいアップデートについても紹介されます。
今回は AWS SDK for JavaScript の Version 3についての Chalk Talk に参加してきたのでレポートします。
Introduction to Version 3 of the AWS SDK for JavaScript (TypeScript) …
Introduction to Version 3 of the AWS SDK for JavaScript (TypeScript)
Chalk Talkでディスカッションする内容は、約10日くらい前にアナウンスされた新しいAWS SDK のものです。
AWS SDK for JavaScriptは現在v2ですが、開発者プレビューのversion3が公開されています。 リポジトリはこちらになります。 github.com
version３の特徴を見ていきましょう。
TypeScript
一番の変更点ですが、TypeScriptで書かれています。
TypeScriptによる恩恵は、エディタによる補完や型推論などを通じて開発効率に現れます。 Google社内でも公式言語として採用されていますし、
かの有名なVSCodeもTypeScriptで書かれています。
ちょっと話がそれますが、VSCodeは re:Inventで発表されたAWS Toolkitsの対応エディタ(現時点ではpreview)のひとつに選ばれるくらい人気があります。 New – AWS Toolkits for PyCharm, IntelliJ (Preview), and Visual Studio Code (Preview) | AWS News Blog
VSCodeを触ったことがなく興味のある方は、以前まとめた記事が参考になるかもしれません。 よろしければご覧ください。 qiita.com
モジュール化
aws-sdk v2がモノリシックな設計だったのに対し、v3ではモジュール化を意識した設計になっています。
そのため、v2に比べていくらかサイズが小さくなっています。 SDKのサイズが小さいことはダウンロードやアップロード時間も短くなるので良いことですね。
一般的なWebにおいては、速さは正義です。
v2の特徴としては、使わないAWS Serviceのクライアントなどもまるっとインクルードされていた為、サービスクライアントを個別にインポートする必要はありませんでした。
しかし、それは本当に便利だったのでしょうか？
たとえば、S3のサービスクライアントしか使わないようなアプリに対して、EC2やEMRなどのサービスクライアントは不要だと思います。
なので、各ソースコードで必要最低限のサービスクライアントをインポートすることでコードの軽量化を含め多くの恩恵が受けられるようになることは、自然な流れだと思いました。
また、ブラウザ側とnode.js側のSDKを分けることで影響範囲を少なくすることにも成功しています。 たとえば、StreamなどNode.jsとブラウザでインターフェイスが違うようなものに関しても、両方のパッケージで適切に処理することができます。
いい感じですね、モジュール化。
プロミス化
各サービスクライアントの非同期的なAPI呼び出しは、コールバックからプロミスに変更されました。 (v2でもAWS Requestオブジェクトのpromise()関数からPromiseオブジェクトを取得することはできます)
いままでは、Promiseオブジェクトを取得する際はpromise()関数を呼び出す必要がありました。
v3ではpromise()関数を経由せずにPromiseオブジェクトが取得できるため、スッキリかけそうです。 さらに aync/await で 統一されていると可読性も高くて嬉しい ですね。
グローバルな設定の廃止
v2では各クライアントのコンストラクタに設定を渡すと、グローバルな設定とマージされるような挙動をします。 そのため、この機能が一部の状態下において混乱のもとになっていました。
そのようなフィードバックを元に、v3からは各サービスクライアントごとに設定することになります。
これは個人的にはすごく良い変更だと思っていて、昨今のアーキテクチャではマルチリージョンで運用するサービス増えているし、 状態としてサービスクライアントに閉じ込めるのはとても自然に感じます。
質問
Chalk Talkだったので、テスト周辺モジュールについて直接質問してみました。
Q「aws sdkってテストがめんどくさいんだけど、mock とか stubとかそういう機能をオフィシャルにサポートする無いの？やっぱりsinonとかproxyquire使ったほうがいい？ 」
A「そういう予定はないけど、aws-mockとかあるから使ってみたら。あと○ｘｋｌｓｊｆｗｆｋｊ....」
... ふむ。なるほど。
わからん。。。
残念ながら英語力不足で最後のセンテンスを聞き取れませんでした。
反省としては、会話の中のaws-mockというキーワードを得ることで満足してしまったところです。 遠慮せずに、「もっとゆっくり話して」って言えばよかったですね。。。
多様な英語に触れてコミュニケーションの経験値を積んで行こうと思います。
ちなみに、その後、ホテルに戻ってきてリポジトリのソースコードを読んでると、テストコードではMockはjestを使っているようでした。
まとめ
このChalk Talkの参加人数は、ざっくり約30人くらいでした。 他のセッションと比べると圧倒的に会場も小さく、人も少ないです。
ですが、小さい会場において、手を伸ばせばすぐ届く距離感だからこそ、登壇者の勢いや伝えたい箇所が強く伝わって来るような気がします。 前回のChalk Talkと比べて、登壇者とリスナーが新しいSDKについて積極的にディスカッションしていたのも印象的でしたね。
個人的な参加目的のひとつとして「AWSのエンジニアに技術的な質問を英語でする」というミッションをひとつを達成できたので、一歩前進という意味でも満足したChalk Talkになりました。
Chalk Talkのような小さいセッションでも手を抜かないのが、re:Inventのいいところですね。
次回は、re:Invent 2018 の総括です。
