Angular场景下Step Function执行完成感知方案选型咨询

方案一：SNS主题+订阅过滤器 #

• 完全可行，但绝对不要为每个PDF单独创建主题——这会导致资源泛滥，后续管理成本极高，完全不符合最佳实践。
• 正确做法是使用统一SNS主题搭配订阅过滤器：Step Function执行完成时，在发送的消息中带上用户唯一标识（比如用户ID、请求ID）作为消息属性；Angular端让用户订阅该主题，并设置过滤规则，只接收包含自身标识的消息。
• 需要注意：用户关闭页面后要及时取消订阅，避免无效订阅堆积；消息属性的过滤规则要配置准确，防止消息串发给其他用户。

方案二：AWS Waiters #

• 技术上可行，但完全不适合你的场景。
• Waiters是轮询机制，Angular端需要反复调用describeExecution接口查询Step Function状态。你的PDF生成耗时可达十几分钟甚至更久，长时间轮询不仅会占用前端资源，还容易触发浏览器请求限制、AWS API调用次数超限问题；而且用户刷新页面后，轮询会直接中断，无法继续追踪任务状态。
• 这种方式仅适合短耗时任务，200+页的PDF生成场景明显不匹配。

更优的替代方案 #

方案三：前端定时轮询+DynamoDB状态存储 #

• 流程：Lambda调用Step Function时生成一个唯一任务ID并返回给Angular；Step Function的每个状态（进行中/成功/失败）都将状态更新到DynamoDB（以任务ID为主键，附带用户ID、PDF链接、状态详情等信息）；Angular使用该任务ID定期调用后端API（比如API Gateway+Lambda）查询DB中的任务状态，还可根据任务时长调整轮询频率（比如前1分钟每10秒查询一次，之后每1分钟查询一次）。
• 优势：比Waiters更灵活，能有效减少API调用量；用户刷新页面后，只要保留任务ID就能继续追踪状态；状态存储在DB中，后续排查问题也更方便。

方案四：WebSocket实时推送 #

• 流程：使用AWS API Gateway的WebSocket服务，Angular页面加载时建立WebSocket连接并附带用户ID；Step Function执行完成后，触发Lambda向对应的WebSocket连接推送完成通知和PDF下载链接。
• 优势：完全实时，无需轮询，前端资源占用极低；用户体验最佳，完美适配长耗时任务场景。
• 注意点：需要处理连接断开重连的情况，确保消息能准确推送给对应的用户。

总结建议 #

• 优先选择WebSocket实时推送，用户体验最佳，适配长耗时任务场景；
• 如果WebSocket实现成本较高，退而求其次选择前端轮询+DynamoDB状态存储，实现简单且稳定性强；
• SNS方案更适合跨系统的通知场景，前端订阅SNS需要处理权限和订阅生命周期，复杂度比前两个方案高；
• Waiters直接排除，不适合你的PDF生成需求。

内容的提问来源于stack exchange，提问作者DaethChanter