從 API Gateway 看前端與後端

假如你是從很久以前就開始做開發，可能有經歷過一段人人都是全端工程師的時光，在當時還沒有所謂的前後端分離，基本上請求從客戶端發送來後，伺服器會去處理所有事情，包含跟資料庫打交道，以及把準備好的 HTML 返回給客戶端。在這個架構下，因為所有東西都放在一起，不論是可擴展性或是故障時的隔離都會比較差。

要能比較有效做隔離，以及讓程式比較好維護，後來發展出把不同的應用做拆分。舉例來說，在一個電商的應用情境下，我們可以把使用者放到 /user、訂單放到 /order 底下、物流放到 /logistic 底下，這樣能做到基本的隔離，也可以讓每個應用變得比較單純，也會比較好管理。

但這種做法也有問題，假如這些仍都是放在伺服器端，這樣與客戶端仍是耦合的，這樣要進一步拓展會比較困難。但是如果兩者解耦合，又會導致前端可能需要大量請求多個不同後端 API，才能在前端組成所需的東西，這個問題在 Theo 的這個影片中有很生動的說明

要解決這個問題，BFF 由此而生。所謂的 BFF 就是指 Backend for Frontend，意思是給前端的後端，這邊強調「給前端的」是對比「與前端解耦的」後端。BFF 在做的事情很簡單，就是在前端與不同的後端 RPC 中間多加一層，然後讓這層 BFF 去處理呼叫不同 RPC 來拿到所需的資料或者處理相關邏輯；而前端則不需用在自己呼叫一堆 RPC，可以只呼叫 BFF 就好。

但是這又會出現一個問題，假如 BFF 是為了特定的前端需求而有的後端，那假如是通用的前端需求，例如常見的驗證 (auth)、限流 (rate limiting) 與平衡負載 (load balancing) 等，這不屬於特定的 BFF，但又是每個 BFF 都需要的，這該由誰來處理呢?

在目前業界的普遍做法，是會交由 API Gateway 來處理，所謂的 Gateway 就是一個入口，在實際進到 BFF 前，會需要先經過 API Gateway 這個入口。舉例來說，假如有個沒權限的人想要呼叫某個 BFF，在 API Gateway 就可以先驗證然後擋下來。

當演進到 API Gateway 的出現，上述過程中會發生的各種事就都能被有效解決，而我們可以有個可拓展、解耦，但同時又能為特定前端提供需求的架構。