3

S3 バケット内の画像のサイズを変更するための Amazon Lambda のサンプル コードを確認しています。 コード例(わかりやすくするために省略):

// Download the image from S3, transform, and upload to a different S3 bucket.
async.waterfall([
  function download(next) {
    // Download the image from S3 into a buffer.
    s3.getObject({Bucket: srcBucket, Key: srcKey}, next);
  },
  function tranform(response, next) {
    gm(response.Body).size(function(err, size) {
      // do resize with image magic
    }
  }
]);
//... more handling code

...非同期ウォーターフォールを使用していることを示しています。ただし、これらの順序付けられた各ステップは、前の関数の結果に依存しているようです。したがって、本質的に、これは順次操作です。

ここで非同期ウォーターフォールを使用する利点は何ですか? これは Amazon での Lambda の実行エンジンと関係があるのでしょうか、それとも単にノードの賢明な設計上の決定でしょうか?

4

1 に答える 1

4

あなたが説明したように、これは基本的に賢明な設計上の決定です。「コールバック地獄」に陥る代わりに、この例の作成者は、基本的に を使用してコードをフラット化しましたwaterfall。

代替コードは次のようになります。

s3.getObject({Bucket: srcBucket, Key: srcKey}, function(response){
  gm(response.Body).size(function(err, size) {
  // do resize with image magic
  }
});

これは読みにくく、処理にステップが追加されるにつれて、はるかに複雑になり、読みにくくなる可能性があります。

于 2015-06-17T13:44:06.500 に答える