# BFF 在 2025 還沒過時，它本來就不是潮流

> BFF 在 2025 還是值得用，它解的是結構問題：同一份後端要餵給性質不同的多種 client，誰面向瀏覽器、誰面向後端、誰扛風險要有明確的一層負責。

原文：https://sheng.page/posts/bff-still-worth-it-in-2025/ · 發布：2025-09-13 · 作者：Sheng

每隔一陣子就會有人問，現在前端框架都能在 server 端跑 loader、能直接打資料庫了，BFF 是不是該收一收。我的看法剛好相反。BFF 從來不是某個世代的流行語，它解決的是一個結構問題：同一份後端，要同時餵給性質完全不同的 client。這個問題沒有因為框架變強就消失，只是被框架的方便包裝掉，讓人以為不存在。

## 一份後端餵不飽四種前端

實務上你很少只有一個前端。對外的 web 要 SEO、要快、欄位精簡；admin 後台要把同一筆資料列到很細，順便塞一堆稽核欄位；遊戲 lobby 要的是低延遲、結構固定、能塞進長連線推播；mobile 又因為流量和電量，希望一次請求就把畫面要的東西聚合好，不要來回往返。這四種 client 對「同一個下游」的需求，根本不是同一種東西。

沒有 BFF 的時候，這些聚合與裁剪會跑到哪去？兩個地方，都不好。一是塞回下游服務，於是某個 user-service 開始長出 `getUserForLobby`、`getUserForAdmin` 這種專門給某個前端用的端點，下游被前端的展示需求綁架。二是塞進前端自己，每個 client 各自打三五個下游、自己拼裝、自己處理失敗，同樣的聚合邏輯在 web、mobile、admin 各寫一份，彼此還會慢慢長歪。BFF 的本質就是把這層聚合與裁剪整合成一個明確的角色：它替「某一類前端」面向後端，前端只跟它對話。

這跟 API gateway 不完全是同一件事。gateway 比較像一條共用的入口管線，做認證、rate limit、路由，盡量對所有人一視同仁。BFF 是有立場的，它就是為某一種 client 而活，回傳什麼、裁成什麼樣，由那個前端說了算。兩者可以疊著用，但別把 BFF 的裁剪責任硬塞進一條想服務所有人的 gateway，那條 gateway 最後會變成沒有人敢動的大泥球。

## 那為什麼不全塞進框架的 layout / loader

這是 2025 最容易踩的坑。現在的 meta-framework 都讓你在 route 的 server 段直接抓資料，很方便，方便到你會想把聚合、外部 API、金鑰通通寫在那裡。問題是這樣邊界會糊掉。

我跑過的其中一個配置是 Nuxt 配 Nitro，server routes 同時當 SSR 的資料來源與 BFF gateway，但有條底線：外部請求不直接碰資料層。前端取資料時走 Nitro 的 server route，由那層聚合下游、補上認證並決定回傳內容，頁面元件只會拿到裁好的資料。某個 loader 若直接 `fetch` 第三方、帶著 API key 對外請求，這條界線就斷了，後面三件事會一起變難。

先看安全。下游服務的位址、內部認證與第三方的 key，一旦出現在會被打包進 client bundle 的範圍，就只能賭 build 工具有沒有幫你切好邊界。把它們關在 server 端的 BFF 裡，client 連這些端點存在都不知道，會比靠規範提醒大家「記得不要外洩」可靠。

版本控制是另一個好處。前端要的資料結構一定會變，今天 lobby 想多顯示一個欄位，明天 admin 想合併兩個列表；如果由前端各自跟下游拼這些結構，每次改動都得請下游與別的團隊一起配合。有了 BFF，前端的輸出變動就留在這層吸收，下游照自己的節奏演進，版本也不用綁在一起。

可觀測性也會好處理得多。所有對外請求都經過同一層後，哪個下游慢、哪個第三方在報錯、這次 render 打了幾次外部請求，都能在 BFF 的 log、trace 與 metrics 裡一起看。聚合邏輯若散在各個前端 loader 裡，想還原一次請求經過哪些下游，就得翻好幾個地方；log 跟 trace 集中在一層，下一個來除錯的人會少熬好幾個夜。

## 小結

BFF 的用途是分清誰面向瀏覽器、誰面向後端，以及誰負責擋住風險。前端專心呈現，下游處理各自的領域，金鑰、轉譯與服務間認證集中在中間這層。框架雖然允許把這些混在一起，通過 build 也只能證明工具鏈沒有報錯。


## 補充筆記

- BFF 解的是結構問題：同一份後端要餵給性質完全不同的多種 client，聚合與裁剪要有個明確的人負責。
- 別把聚合塞回下游（端點被前端綁架）或塞進前端（邏輯重複長歪），那只是在搬動問題。
- meta-framework 的 loader 很方便，但外部請求不該直接碰資料層，否則安全、版控、觀測會一起變難。
- BFF 幫的三件事：把金鑰與下游藏在 server、前端輸出變了只改 BFF、整條 call chain 集中觀測。
- 能 build 不等於設計合理；BFF 的價值是把「誰面向誰、誰扛風險」這條界線畫清楚。
> 想法與技術判斷出自 Sheng，和 Claude 一起起草 · 列入 20260613 blog 翻新計劃，新漆未乾。