學習後端基礎 2 - 後端通訊設計模式
上一回我們介紹了最基本的 Request–Response，以及同步與非同步的概念。那些都是「事情馬上就會有結果」的情境，但在真實世界裡，更多時候是——事情還沒發生，但我們已經在等了。
例如新訊息、訂單狀態、外送進度、即時通知。
問題不在於怎麼拿資料，而是：
資料還沒出現的時候，系統要怎麼應對？
這時候，就會出現幾種不同的設計方式，其中最常見的就是 Polling、Long Polling 與 Push。
Polling：每隔一小段時間就再問一次
Polling 是最直覺、也最符合人類本能的一種做法。
不知道狀態有沒有更新，那就隔一段時間來確認一次。
就像你在等一個重要訊息，忍不住一直拿起手機解鎖看看有沒有新通知。大部分時候什麼都沒有發生，但你還是會不斷確認，因為你不想錯過。
我自己實作過、印象很深刻的一個例子，是串接 TW FidO 的行動自然人憑證驗證服務。使用者在登入頁面上會看到一個 QR code，接著拿出手機，用行動自然人憑證 App 掃描並完成登入。但這時候其實會出現一個問題：手機那邊已經登入成功了，電腦畫面怎麼會知道？
電腦畫面並不會「自動感應」使用者的登入狀態，它能做的事情其實很單純——就是隔一小段時間，偷偷跑去跟伺服器確認一次：「這個人是不是已經完成登入了？」大多數時候，答案都是「還沒」，畫面就繼續停在原本的登入頁面。但一旦使用者在手機上完成驗證，下一次確認時，伺服器就會回傳「已登入」，畫面也就順勢跳轉到登入後的頁面。
如果您有申請行動自然人憑證 app，可以玩玩看這個網站的登入功能。如果您有一點前端背景，可以打開 DevTools，就可以明白我說的了：ODF QA
在系統裡，Polling 的行為也差不多。
客戶端每隔幾秒或幾十秒，就向伺服器發送一次請求，詢問是否有新資料。如果有就拿走，沒有就等下一次。
這種方式的好處在於它非常單純，幾乎沒有理解門檻。不需要特殊的連線機制，也不需要複雜的狀態管理。但問題也很明顯——大多數的詢問，其實都是白問的。資料沒有變，請求卻一直來，這就是很消耗資源的行為。可以想像一下，你一直在等 crush 的訊息，每隔兩分鐘就想看一下手機，但是她可能過了兩天才會回你。這不但對你來說會覺得很煩，對手機也很耗電。
因此 Polling 更像是一種「能用就好」的方案，適合資料變動頻率低，或系統規模還不大的時候。
Long Polling：你先別走，有消息我再跟你說
Long Polling 可以說是對 Polling 的一種改良。
既然一直來問很浪費，那不如這樣：你來問一次，我如果現在沒有資料，就請你先等等。
在這段等待的時間裡，伺服器並不會馬上回應，而是等到真的有新資料出現時，才把結果回傳給客戶端。回應結束後，客戶端再立刻發出下一次請求，繼續等待。
這有點像你打電話給客服，對方請你稍等幫忙確認資料，而不是叫你掛掉電話、過一分鐘再重打一次。你不用一直重複同樣的問題，但一有結果，對方會立刻告訴你。
相較於 Polling，Long Polling 少了大量無意義的請求，也讓資料看起來「幾乎是即時的」。不過代價是，伺服器必須同時維持很多尚未完成的請求，對資源管理的要求也更高。
它依然屬於 Request–Response 的模式，只是把「回應的時間點」往後延了。
Push：事情發生了，我主動通知你
Push 模式的思維，則是完全反過來。
既然客戶端不知道什麼時候該問，那乾脆就不要問了。等事情真的發生時，由伺服器主動把資訊送出去。
這就像你訂閱了一個通知服務，訊息一出現，系統就直接提醒你，而不是要你自己反覆查看。你不需要做任何動作，資料自然會來找你。
即時聊天、即時通知、股票報價、線上遊戲狀態，幾乎都是這種模式。它帶來的是最好的即時性與使用體驗，但同時也意味著更高的系統複雜度。伺服器需要處理長時間存在的連線，還要考慮斷線、重連、擴充性等問題。
Push 很強很即時，但也不是所有系統都需要用到它。
看完了這三種方式，看起來 Push 模式好像比較理想，又快又即時。但沒有哪一種方式是「一定比較好」。Polling、Long Polling 和 Push，其實都是在回應同一個問題，只是站在不同的角度。
有些情境不需要即時，有些情境不能浪費資源，有些情境則是使用者體驗優先。選擇哪一種方式，從來不是技術炫技，而是取決於你想解決的是什麼問題。
當理解這些模式背後的思考方式之後，再去看 WebSocket、Server-Sent Events 或 Pub/Sub，就不會只是在記名詞，而是能理解它們為什麼會存在。
