为无服务器的Web应用程序带来实时性ITNEXT

在此图中，一些前端代码调用API网关，从而在DynamoDB中生成一个条目，该条目生成一个流，触发Lambda函数。但是最后一个Lambda函数的返回值无处可去。因此，如果出现错误，问题或需要原始前端代码知道的问题，我们就会陷入困境。

实际上，每当您将函数附加到从S3，DynamoDB或任何其他AWS服务生成的事件时，返回值都不能被推回到链中。例如，如果使用Rekognition分析放入S3 Bucket的照片，则需要将响应发送到函数返回值以外的其他位置。
这些问题有几种解决方案，每种方法都有各自的优缺点，具体取决于您的使用情况。

选项1：等待
在最简单的情况下，你有一个需要一段时间的功能，你可以等待。您受限于API网关的30秒超时，因此对于长期存在的进程，这是行不通的。从成本的角度来看，这也不是很好，因为你在为等待付出代价。但对于简单，临时，低使用率的应用程序，这是最简单的解决方案。
示例：每月一次，前端请求将大对象从一个S3存储桶复制到另一个区域，并等待3-5秒，直到S3确认成功完成。在这种情况下，设计更复杂的东西可能不值得。

选项2：轮询
这适用于后端进程花费的时间超过几秒钟，或者执行的长度可能超过API网关上的30秒超时的情况。
这里前端提出了API的请求，发生了两件事：

• 被叫函数立即响应，确认已成功接收请求（但不是工作结果）。此响应可能包括稍后引用的前端ID（如果前端未首先生成ID）。
  
• 接下来，有一个用于检查工作状态的第二个API，并且前端将定期轮询，直到工作报告为完成，并且该函数返回响应。在AWS中，此状态函数通常会检查DynamoDB表，其中包含管理请求状态的ID。
  

选项3：物联网

虽然IoT会让人联想到硬件设备的图像，但它也可以用于无服务器的Web应用程序。物联网使用称为MQTT的轻量级消息传递协议，这是一种简单有效的推送消息的方法。

发布 - 订阅方法通常保留给实时应用程序，但可以很好地解决此问题。好处是您不需要编写轮询功能或发出多个必要的请求，并且您不受API网关30秒超时的限制。更好的是，无论过程需要5秒还是5分钟，前端都会立即知道任务何时完成，因为通信是实时的。
对于诸如仪表板之类的前端而言，这是一个很好的解决方案，其中网页加载一次但希望与后端数据的更改保持同步。但它对于任何时间要求严格的前端应用程序也很有效，因为您希望最大限度地减少等待时间。
在表面下，发布 - 订阅是复杂的，它是一个繁琐的过程，定期保持活跃的ping，以确保各方仍然存在。幸运的是，AWS IoT设备SDK将这一切抽象出来，使我们可以轻松构建一个前端，该前端正在侦听后端某些远程进程生成的消息。

从成本角度来看，AWS通过连接分钟和消息数量向您收费（还有一个慷慨的免费等级补贴）。连接一年的单个客户将花费4.2美分（不包括数据费用），因此如果您有数千名用户，美元很重要，那么它仍然相对便宜。