まえおきdevとopsが異なるチームでopsが不定期にデータを抽出・集計したい時にopsが利用できるツールやアプリがあれば依頼が無くなりお互い幸せですよね・・・というのはわかっていたものの中々腰が上がらなかったのですが、serverlessフレームワークを利用してみたかったので丁度よい題材という事で今回Slackのスラッシュコマンドを作成した話です。スラッシュコマンドSPAなどのWebアプリケーションを作成するのも一つの手ですが、Slackのスラッシュコマンドでどんなスラッシュコマンドを実行したのかも含めて結果を表示できれば、チームメンバーは他のメンバーがどういったコマンドを実行してタスクをこなしているのかを見る事が出来ます。これにより他のメンバーも、使い方を理解してそのコマンドを使っていくことが出来ます。背中を見て育つって寸法です。今回始めてスラッシュコマンドを作成したのですが、スラッシュコマンドは3秒以内に応答を返さなければタイムアウトになってしまいますが、LambdaからDynamoやS3のデータを処理するにしても大体3秒以上かかるものです。タイムアウトになってしまうと、スラッシュコマンドの実行者がどんなコマンドを実行したのかが、他の人には見えてきませんので、今回の目的としては3秒以内に応答を返す必要があります。パラメータがあり、このURLへデータを送信する事で3秒が経過した後にも応答を表示する事が出来ます。処理結果を返す形にすると目的が達成出来ます。ランタイムのイベントループが空になるまで待機してから処理を停止し、呼び出し元に結果を返します。図にするとこんな感じになります。Gatewayから起動されるLambdaは他のLambdaを呼び出し、3秒以内にレスポンスを返すだけですので、ほぼnpmモジュールが必要ありませんし3秒以内に応答するためにコンテナの起動速度は可能な限り高速化したいのでサイズを小さくしたい欲求があります。そのまま全functionにぶっこんできます。excludeを追加できるような対応となっていました。ディレクトリ構成は階層がフラットなのでfunction毎に依存するモジュールだけを列挙するのは現実的ではありません。plugin「各function毎に必要なモジュールを解決してまとめて欲しい」・・・そう、最早フロントエンドには欠かせないモジュールバンドラの出番ですね。webpackでバンドルして、それをserverlessでアップロードして〜というタスクを書いてもいいんですが丁度良くserverlessのwebpackプラグインというのがあります。handler毎に依存しているモジュールをバンドルしてくれます。これで各functionのpackageディレクティブには何も記述する必要はなくなりました。Lambdaはaws-sdkパッケージはLambda側に入っているのでバンドルする必要はありません。書いておけば除外されます。コンパイルさせようって思いますよね。書くとtscではコンパイル通るのにts-loaderでは挙動が変わってビルドに失敗したりしました。全部TypeScriptで書けってお達しなんでしょうか。完成!完成です!コチラが設定ファイル群です!(Lambdaの実コードは特に面白い事はないので割愛)各種設定パラメータをまとめたconfig.jsonがステージングの時と本番の時で異なるのでdeployとdeploy:prodで分けています。deploy:prodでデプロイしてます。cliプロファイルを分けています。本番の時はステージ変数を--stageでprodに指定すれば諸々切り替わるcustomセクションを書いてます。IAM権限はありもののRoleで良い感じのものがあるので、SAMで作成せずにそれを利用するようにしました。厳密に権限設定するならSAMで書いたほうがよいでしょう。今回の構成上、index関数から別の関数をinvokeする必要があり名前が必要なのですが、serverlessによってLambda関数名が<service名>-<stage名>-<function名>になるのでLambdaの環境変数としてservice名とstage名を設定するようにして取得しています。/checkpos"webpack.全く追ってないですがserverless-webpackのlib.entriesでhandlerをリストアップしてくれるんだろうと思ってます。removeでまとめてサクッと削除できて便利でした。VSCodeAtomも好きなんですがTypeScript書くならVSCodeだな、となりました。upLoginユーザーは見つかりませんでした。