目錄
簡單工程如何運作
-
前端呼叫後端 API 。
-
後端 API處理請求並發迴回應。
-
前端相應地呈現響應。
當您建立 MVP 時，這非常有效。
當我們決定擴展專案或使專案成熟時會發生什麼
-
後端 API 開始遵循單一職責原則。
-
API 可以組合到服務中，或者可以引入微服務。
-
客戶端程式碼變得更加複雜。
-
請求-回應結構的頻繁變化在前端和後端之間變得很常見。
-
更多資料被加載到前端。
-
當處理多種客戶端類型（例如網路和行動）時，API 變得更加臃腫。
-
多個並發請求發送到後端來解決頁面 UI 需求。
這可能會變得像我女朋友沒完沒了的要求清單一樣令人難以承受。因此，為了提供幫助，我的一位資深隊友向我介紹了BFF的概念。無論是在現實生活中還是在程式碼中，最好的朋友總是為您提供支持。
BFF 到底是什麼？ 🤔
前端特化後端 (BFF)是一個中介者，可以根據不同客戶端的特定需求客製化後端服務。將其視為最好的朋友，過濾所有混亂並只為您提供您需要的服務。前端呼叫 BFF 伺服器 API 端點，然後 BFF 執行繁重的工作，呼叫所有所需的後端服務。
BFF 如何幫助擴展專案🛠️
在這種情況下，為什麼還要維護另一個中介伺服器 BFF？為什麼不堅持使用舊的且經過驗證的兩層架構呢？
因為現在我們關心的是使用者體驗！我們不再是MVP了，不能像無頭蒼蠅一樣到處亂跑。
我們的後端 API 遵循單一職責原則，但我們的 UI 需要大量資料，這意味著要呼叫許多後端 API。問題是大多數瀏覽器只允許每個網域 6 個並發請求。您可以透過此Stackoverflow執行緒閱讀有關此限制的更多資訊。因此，如果您的儀表板顯示來自 3-4 個服務的資料，每個服務都有許多 API，則瀏覽器一次只能處理 6 個。一旦完成這些，它就會處理接下來的 6 個。
輸入BFF：客戶端對BFF進行單次呼叫，BFF對所有服務進行所有呼叫，不受並行連線限制。問題解決了！
但如果並發連線數不是問題怎麼辦？您還應該使用 BFF 模式嗎？我的答案是肯定的！
假設您有一個儀表板，顯示來自 3-4 個服務的資料。在將資料顯示給最終使用者之前，您可能會進行一些特定於客戶端的計算、調整或轉換。對於小塊，在客戶端執行此操作效果很好。但隨著資料轉換變得更加複雜，它成為使用者體驗的瓶頸。 JavaScript 是單線程的，UI 開始感覺滯後或不穩定，因為瀏覽器忙於轉換資料而不是為 UI 提供服務。
一個簡單的解決方法：將所有表示、適應或轉換邏輯移至 BFF。這樣，客戶端的瀏覽器就可以自由地專注於渲染內容。另外，BFF 會適應後端 API 回應結構的任何變化，因此前端會看到一致的回應結構。
但是 BFF API 變得太籠統或臃腫怎麼辦？是不是也需要遵循單一職責原則？
對 BFF 來說，單一責任原則有點不同。理想情況下，單一 BFF 伺服器端點應該會載入或更新與單一 UI 頁面相關的資料。不同的客戶端類型（例如行動用戶端和 Web 用戶端）可以擁有自己的 BFF 伺服器。每個 BFF 伺服器都會向客戶端發回一個精簡的、客製化的回應。行動裝置比 Web 佔用更少的資源，因此 BFF 伺服器可以輕鬆調整回應。
因此，雖然與後端服務 API 相比，BFF 伺服器 API 可能顯得臃腫且通用，但它們仍然遵循單一職責原則。
在現實世界中使用 BFF 🌍
設定和探索開源專案
- 專案設定：
-
依照專案自述文件中的步驟設定專案。
-
設定完成且伺服器執行後，請造訪https://localhost:3000/dora-metrics 。
- 開啟網路標籤：
-
開啟瀏覽器的開發人員工具（按
F12或Ctrl+Shift+I）。 -
轉到“網路”選項卡以監控 API 呼叫。
- 觀察 API 呼叫：
-
請注意，頁面從
/internal/team/${team_id}/dora_metrics的回應載入大部分資料。 -
這是一個 BFF API 端點，負責載入
/dora-metrics路由頁面所需的所有資料。
- 檢查程式碼庫：
-
導航至
/internal/team/[team_id]/dora_metrics模組的程式碼。 -
使用
Promise.all觀察多個後端服務的並發呼叫。
- 了解好處：
-
在底層，我們呼叫 5 個不同的後端服務，總共 18 個 API 呼叫。
-
如果從前端進行相同數量的呼叫，則可能比使用 BFF 方法多花費 3 倍的時間。
遵循這些步驟將幫助您了解如何在實際專案中實現 BFF 模式，並了解它在效能和使用者體驗方面帶來的好處。
使用 BFF 的好處🌟
-
改進的使用者體驗：透過將複雜的資料轉換和聚合卸載到 BFF，客戶端的瀏覽器可以專注於渲染，從而獲得更流暢的 UI 體驗。
-
最佳化的 API 呼叫：BFF 可以將多個後端 API 呼叫聚合為一個呼叫，從而減少客戶端需要發出的請求數量。
-
客製化回應：不同的客戶端（網路、行動）可以擁有其特定的 BFF 伺服器，確保每個用戶端收到適合其需求的資料。
-
適應性：BFF可以適應後端API結構的變化，為前端提供一致的介面。
總而言之，當應用程式從 MVP 發展到成熟產品時，採用 BFF 模式可以顯著提高應用程式的可擴展性、可維護性和使用者體驗。請記住，無論是在程式碼中還是在生活中，好朋友始終是您的後盾！
如果您發現本文有幫助並且喜歡探索 BFF 模式，請考慮為中間件儲存庫加註星標。您的支持有助於我們繼續改進並與社區分享有價值的內容。謝謝你！
{% 嵌入 https://github.com/middlewarehq/middleware %}
原文出處：https://dev.to/middleware/best-architecture-for-your-next-project-framework-doesnt-matter-29em
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
