昨天在 frontend 社團有 backend 工程師來發問「一個要花費 20 秒的 API，backend 難道不能讓 frontend 等 20 秒再回傳給 frontend 嗎？為什麼有些做法都是先回 201 然後再用 websocket 回傳結果呢？」
當然可以啊，但使用者體驗會很差，這裡把昨天小編的回文拿回來再補充一下。
---
一個 20s 的 request 會遇到幾個問題
1. client 的話的使用者體驗很差，在瀏覽器等了 5s 我就想關網頁了，更何況 20s。
2. 如果使用者在 5s 的時候關網頁，這時候 server 還是會繼續把後面的 15s 處理完。
3. 如果使用者此時又發 request，然後在 7s 的時候又關網頁，這樣子有兩個耗時的工作在後端處理，而且還沒辦法讓前端知道。
4. 使用者都很沒有耐心，如果有 10 個人重複做了 2 3 步，這樣就有 20 個耗時的工作。
5. 如果是 CPU bound task，你的 server 應該會卡死。
6. client 跟 server 各自都有 timeout 的設定，而且 server 前面如果還有擋 nginx 或是其他 cloud provider 的話，光是 timeout 的設定就搞死你了。
---
建議的作法，把真的必要的工作處理完，threshold 最多設 3s，超過的一律丟到 MQ 處理。然後在前端顯示，請他稍後再回來更新網頁，這是最簡單的。每個系統 (OLAP 或 OLTP) 的 threshold 不同，請自行考量。
要不然 polling 也行，每 3 秒拉一次，確認工作是否完成。
最聰明的當然就是透過 push notification 或 websocket 讓 client 得知工作是否已完成。
---
https://hahow.in/cr/kewang-backend
看到這裡，要宣傳小編的後端課程啦！上面回答的這些內容，都會在課程裡面分享喔，還不快去下單！
#backend #frontend #mq
push notification 在 What Are Push Notifications on Facebook? - Lifewire 的推薦與評價
Think of a Facebook push notification as an alert that pushes through the closed app to make you aware of any Facebook activities that may ... ... <看更多>