在Web應用程式中，通常會有一個前端與REST API進行通訊，以便在後端完成工作。通常，API會返回一個結果，表示您要從系統中檢索成功或某些值。

但是在無伺服器基礎設施中有一種棘手的型別的呼叫，其中返回值“消失”或者很難推回到前端，因為它需要太長時間或者 - 由於事件的連結性質 - 來自呼叫者需要更長時間才可以訪問最終結果。

看看這個例子：

在此圖中，一些前端程式碼呼叫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。

這種方法易於實現，但會產生許多不必要的請求，並且不是很實時。例如，如果事務需要20秒並且前端每秒輪詢一次，則在前端收到完成的響應之前需要20-21個輪詢請求。

在無伺服器方面，從成本的角度來看，這可能仍然是優選的 - 20 x 100ms的請求成本低於等待20秒，但是有一個開銷，而且程式碼相當於在車後面讓孩子們反覆詢問“我們還在那裡嗎？ ？”。

選項3：物聯網

雖然IoT會讓人聯想到硬體裝置的影象，但它也可以用於無伺服器的Web應用程式。物聯網使用稱為MQTT的輕量級訊息傳遞協議，這是一種簡單有效的推送訊息的方法。

釋出 - 訂閱方法通常保留給實時應用程式，但可以很好地解決此問題。好處是您不需要編寫輪詢功能或發出多個必要的請求，並且您不受API閘道器30秒超時的限制。更好的是，無論過程需要5秒還是5分鐘，前端都會立即知道任務何時完成，因為通訊是實時的。

對於諸如儀表板之類的前端而言，這是一個很好的解決方案，其中網頁載入一次但希望與後端資料的更改保持同步。但它對於任何時間要求嚴格的前端應用程式也很有效，因為您希望最大限度地減少等待時間。

在表面下，釋出 - 訂閱是複雜的，它是一個繁瑣的過程，定期保持活躍的ping，以確保各方仍然存在。幸運的是，AWS IoT裝置SDK將這一切抽象出來，使我們可以輕鬆構建一個前端，該前端正在偵聽後端某些遠端程式生成的訊息。

從成本角度來看，AWS通過連線分鐘和訊息數量向您收費（還有一個慷慨的免費等級補貼）。連線一年的單個客戶將花費4.2美分（不包括資料費用），因此如果您有數千名使用者，美元很重要，那麼它仍然相對便宜。