如何知道lambda图像压缩是否完成？

问题描述

我正在使用 apollo-server-express 制作一个 GraphQL API 服务器。

为了允许用户将他们的图像上传到 S3，我做了一个名为 userContentFileUpload Mutation 的突变，其架构如下所示：

type Mutation {
  userContentFileUpload(file: File!) {
    uploadUrl
    fileUrl
  }
}

uploadUrl 是用于上传图像文件的预签名 S3 URL，fileUrl 是 S3 URL，包括上传图像文件将具有的密钥。

因此客户端可以按如下方式使用此 API：

使用 uploadUrl 或 fetch 将图像文件上传到 axios。
等待上传请求成功。
使用 fileUrl 作为上传文件的远程 URL。

现在我正在尝试添加一个 AWS lambda 函数来压缩上传的图像。

lambda 函数将：

由 S3 文件上传事件触发。
压缩上传的文件。
将压缩文件放入 S3 存储桶。

但是，由于向 uploadUrl 的上传请求会在 lambda 函数的第 1 步之前完成，所以客户端开始使用 fileUrl 的时间和压缩文件的时间会有一定的差距实际放入 S3 存储桶中。

我怎样才能填补这个空白？？

解决方法

据我所知，您现在有两个一般选项：

在收到图像时对其进行压缩（称为静态再现）。
交付时压缩图像并缓存结果（有时称为动态再现）。

这是您在所有资产交付系统中都有的两个选项。这两种方法各有优缺点。

由于您没有提供很多详细信息（图片大小、使用模式等），因此很难说两者中的哪一个更适合您。

因此，我将向您提示如何在 AWS 中实现两者。

如果您想在收到图像时对其进行压缩，并且只想在图像压缩时允许访问 fileUrl，则可以切换到 Step Functions。由于几个月API Gateway allows you to send incoming requests directly to express Step Functions进行处理。因此，您可以创建一个 Step Function 来下载图像，创建压缩版本，然后返回给调用者。显然，这是有局限性的。图像越大，处理可能需要的时间越长，您可能会超时等。所以上传 2MB 的图像，没问题。上传 1GB 大的图片，这可能会成为一个问题。

您的第二个选择是在交付时压缩并缓存结果。如果您使用 AWS Cloudfront,you can use Lambda@Edge 来执行此操作。但您也可以使用 S3 Object Lambdas。

可能还有更多选项可以构建这样的东西。但是如果没有更多细节，就很难找到最适合您的解决方案。

amazon-s3 aws-lambda image-compression