今日はAPIGatewayをどうやったらリソースプロキシとカスタムオリジンのパスに対応したリソースをlambdaに送れるか検証していた。
前提
APIGateway+lambdaでlambda内でルーティングを行う
カスタムオリジンのマッピングのパスに任意の文字列を追加する
この時、lambdaのルーティングが正常に処理されるようにしたい
考えたこと
App側でeventを受け取った時にマッピングのパスを除外する
Lambdaプロキシ統合を諦め、マッピングテンプレート内でマッピングのパスを除外する
App側処理
最初に考えたのがこれだった。
goのginで実装していたサンプルのginLambdaに渡すrequestのPathで環境変数から受け取ったprefixがpathに存在する場合に除外する処理を書いた。
これは大変だった。
buildしてimage pushしてlambdaでtestしてみて・・・という手順で実行していたのが手間だった。
ローカルでlambdaにeventを送って検証する手順をちゃんと理解したら楽なんだろうなってなった。。
App側やりながら、そもそもAPIGateway側でやってほしいってなった。ただAPIGateway初心者なので、どのようにリクエスト、レスポンスがlambdaに渡ってきているのかよく分かってなかった。
APIGateway側処理
マッピングテンプレートというものがあるらしい。<-そこで処理書けないか
Lambdaプロキシ統合ではマッピングテンプレートは使えないらしい。<-諦めてみる
した時に、マッピングテンプレートはVTLを使っていてVTLを使うことになった。
まずリクエストとレスポンスをLambdaプロキシ統合のレスポンスと同様にした。
マッピングテンプレートのイヤなところは、
playgroundが無いところ
書き方ミスっててもテストしてみないとわからないところ
そして書いてテストがめちゃくちゃ手間だった。
CLIとかで簡単にテスト出来たらいいけどやり方わからずひたすら行き来していた。
utilとか使えないらしくずっと色々もごもごやっていた。
結果、`$value.substring($proxy.length())`のような書き方で値を除外した。
あとプロキシリソースを使っていたのでそこでも詰まっていた。プロキシリソースのパスは違うところにあるので・・
細々、apigatewayのログをオンにしているのになぜか載らない、マネジメントコンソールで作成したものは動くのにコードで作成したものは動かないでも詰まった。
結果、前者はコードのログの向き先が間違っていた・・・
後者もカスタムオリジンに割り当てていた向き先が違うAPIリソースだった・・・
レスポンスメソッドを200しか使ってないのでそれ以外のステータスの時きちんと違うステータスで返ってくるようになっているか
マッピングテンプレートの書き方間違えていないか・・・(除外したいだけだったけど、一応パスパラメータやヘッダーも送れるように書いたため）
デプロイフローできちんとデータが更新されるか
色々心配である
ステージ変数なんに使うの？って思ってたけどマッピングテンプレートで活用出来たのはよかった :v: