photos現在、S3 には 2 つのバケットがあります。それらを と と呼びましょうphotos-thumbnails。現在、ユーザーが iOS アプリから画像をアップロードすると、その写真をphotosバケットに直接アップロードします。これにより、写真のサイズをサムネイルに変更し、サムネイルをphotos-thumbnailsバケットにアップロードするラムダ関数がトリガーされます。
photos元のバケットにサムネイルを作成する前に、バケット内の画像の画像圧縮を含める必要があります ( photos)。ただし、バケットにオブジェクトが作成されるたびに圧縮ラムダ関数がトリガーされるように設定するphotosと、ユーザーが元の写真をアップロードし、圧縮をトリガーして同じバケットに戻すという終わりのないループに陥ります。圧縮を再度トリガーするなど。
画像圧縮の再帰呼び出しになる前にこれを傍受できる方法はありますか? それとも、3 番目のバケットを作成する唯一の方法ですか?
3 番目のバケットがおそらく最適です。本当に同じバケットを使用したい場合は、画像をphotos変更するかどうかを制御するいくつかの基準 (おそらく画像ファイルのサイズなど) を選択し、一度処理された画像がしきい値を下回っていることを確認してください。ラムダは引き続き 2 回実行されますが、2 回目は画像が検査され、既に処理されていることがわかり、再度処理されません。私の知る限り、ラムダの 2 回目の実行を抑制する方法はありません。
もう 1 つのオプションは、オブジェクトの作成方法に基づいてフィルタリングすることです。S3 では、次のイベント タイプを使用できます。1 つはユーザーがアップロードするもの (おそらく POST?) に使用し、もう 1 つはラムダが行うこと (おそらく PUT?) に使用します。
3 番目のバケットが機能するか、基本的に同じことで、圧縮後にプレフィックスを使用してファイルの名前を変更し、ファイルを再処理する前にそのプレフィックスをチェックします。
関数の出力に予測可能な名前を付けると、関数の開始時に関数によって作成されたファイルをフィルター処理できます。
ただし、前述のように、出力に別のバケットを使用する方が簡単です。