[Lambda] Binary Invoke API
- 主要言語
- 言語のデータがありません
- スター
- 196
- フォーク
- 5
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
It would be excellent to have a binary API for invoking Lambdas, and receiving responses.
**Which service(s) is this request for?**
This is a request for Lambda proper, but could benefit integrations with other services (AWS and 3rd party) as well.
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Many use cases for Lambda involve processing binary data (network, images, data, etc.). The current REST API requires two full encoding/decoding passes:
- The calling code must encode the binary data to invoke the lambda.
- The Lambda function decodes the request to process it.
- The Lambda function encodes the response.
- The calling code decodes the response.
In addition to the encoding and decoding compute being a burden at scale, encoding inflates the size of payloads (hence reducing the effective payload size).
Removing the encoding would reduce complexity in customer code, reduce compute consumption and increase the effective request and response payload size.
**Are you currently working around this issue?**
At Proxylity we encode each UDP packet arriving at our service before passing to Lambda. An arriving packet is serialized to JSON with the binary data being base64 encoded before sending to Lambda. Our customers then write (or use library) code that handles the de/reserialization. Our code then decodes the JSON response and sends a the binary data in a UDP response. The encoding alone can account for as much as a third of the CPU time overall for simple handlers.
**Additional context**
I understand this ask may sound daunting, but could it perhaps be compatible with the current runtime API as an underlay (pre deserialization/serialization)?
**Attachments**
None at this time.
コントリビューションガイド
調査の方向性
ファイル、テスト、実装のエントリーポイントは指定されていません。まず、現在の REST Invoke API のエンコーディングパスと、issue で説明されている Runtime API の互換性に関する問題を整理してください。説明されているエンコーディング処理を回避し、関連する AWS およびサードパーティーの統合で動作する、定義済みのバイナリ request/response API が実現されれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- aws
- 領域
- api, cloud
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100