Lambda統合とLambdaプロキシ：長所と短所
AWS API Gatewayでプロキシ機能を使用する場合と使用しない場合（具体的には、サーバーレスフレームワークを使用する場合）にLambda統合を使用する長所と短所は何だと思いますか？これまで私が考えていることは次のとおりです。
Lambdaとプロキシの統合
- Pro：必要なすべての構成の詳細を心配することなく、迅速にプロトタイプを作成してコーディングできます（汎用テンプレートマッピングなどのいくつかのホイールを再発明します）。
- Pro：ステータスコードとカスタムヘッダーを返すのは非常に簡単ですが、同時にリクエストの本文、ヘッダー、パラメーターを読み取る一般的な方法があります。
- Con：すべてがコードで実行されるため、ドキュメントの自動生成は少し難しくなります。依存関係（ヘッダー、モデル、返されるステータスコード）は、コード内で「隠されています」。
プロキシなしのラムダ統合
- Con：それをセットアップするために多くの作業が含まれます、この構成は異なるリソースに複製される可能性があります。
- Pro：ラムダが受信して返すものと、ラムダが異なるHTTPステータスコード、ヘッダー、およびペイロードにマッピングされる方法を分離できます。
- Pro：返されるもの、およびヘッダーとペイロードに関して必要なものを事前に規定するため、非常に便利です。
- Pro：すべてをSwaggerにエクスポートできるため、すべてをセットアップする際のハードワークは長期的に役立ちます。他の人はこれを使用して、異なるSDKを生成できます。
あなたの考えは何ですか？通常、Lambdaプロキシまたは単純なLambda統合を使用しますか？あなたは何を好みますか、そしてなぜですか？
[〜＃〜] edit [〜＃〜]：これまでのところ、言及されている理由により、プロキシ機能を使用しないことを常に選択する傾向があります（依存関係の分離と状態-ヘッダー、ステータスコード、など-前払い）。
プロキシなし。
実稼働環境でいくつかのSLSを展開していますが、一部は内部ツールとして収益を生み出しています。私は排他的にプロキシを使用しません。アプリケーションのAWSの構造に依存したくないので、友だちになるのをやめれば、あまり苦痛なく移行できます。
プロキシの長所については、あなたも短所であると感じているので、私はそれらを短所と見なします。 「超高速で動く」前に私はそれをすべて見てきました。はい、私たちは敏gで迅速に行動する必要がありますが、思考を犠牲にする必要はありません。私は常にエンジニアと一緒にこれを手に入れています。その1つは、ドキュメント/デザインが少なく、もう1つは「計画の要点はコーディングだけです」と言うことです。それは、市場投入の速さに関わらず、自分を追い詰める方法です。プロキシがなく（プロジェクト構造の初期計画もあり、DDDの考え方もあります）、世界が燃えた場合にAWSから移行するのは非常に簡単です。
これに加えて、AWSのもので新しいボードを高速化するのは非常に難しいと思います。一度それを知ったら、開発者はインフラストラクチャエンジニアではなく開発者です（両方を行う私たちは驚くほどまれです）。抽象化することで、人々がラビトホールを下る困難な旅を始める際の生産性が向上します。私のコーダーコードは20分ごとにCFNを気にする必要はなく、むしろIdです。
AWSのように見えます 新しいAPI開発にLambdaプロキシ統合を選択することをお勧めします 。
注意
以前はLambda統合と呼ばれていたLambdaカスタム統合は、レガシーテクノロジーです。新しいAPIにはLambdaプロキシ統合を使用することをお勧めします。詳細については、Lambdaプロキシ統合を使用したAPI Gateway APIの構築を参照してください。
カスタム統合ではなくプロキシ統合を使用してAPIエンドポイントとラムダ統合をスピンアップすることは（短期的に）かなり「速い」ことを理解していますが、の推奨事項に驚いていますallAPI/Lambda開発の今後：
- API Gatewayが「HTTPの詳細」を処理する責任があると考えました。プロキシ統合を使用すると、その責任（少なくともそのサブセット）がLambda関数に強制されます。 （つまり、HTTPヘッダー、クエリパラメーター、ステータスコードなどの解釈および決定方法を知っている）
- そうすることで、muddiesバッキングLambda関数の責任であると感じます-Lambdaは、実行するために呼び出される「ビジネス」ロジックを処理する必要があります。着信HTTP値を解釈し、発信HTTP応答値を決定します。
- 確かに、追加のLambda関数レイヤーを実装してHTTPの詳細を抽象化することもできますが、それはAPI Gatewayが行うべきことではありませんか？
- 非HTTPクライアントがHTTPリクエストのようにリクエストをフォーマットしない限り、HTTPリクエストのサービス以外のコンテキストotherで特定のLambda関数を再利用する機能を低下させます。
たくさんの機能を実行するのが本当に速いと感じたので、プロキシから始めました。すぐに、Proxyが入力の読み取りと出力の書き込みを強制する方法と非常に緊密な結合を作成し、関数がこれを認識せず、より明確でシンプルなインターフェイスを持つ必要があることがわかりました。そして、それらの関数のいくつかを AWS Step Functionsでオーケストレーションし始めました。それは、プロキシ統合でのみ実際に機能する関数を作成したことに気づいたときです 。ステップ関数ではなく、それらは簡単に移行できないことは確かです。
もうプロキシはありません。