本文翻譯自PhilCal?ado的官網：https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html

對我們的架構演變保持透明是我們技術戰略的一部分。我們在無數場合談過的但從未真正詳細描述過的東西是我們應用后端用于前端架構模式或BFF。這篇文章記錄了我對如何開發和應用這種技術的理解。

我對軟件組件演變的理解

在完全分布式架構變得可行之前，組織通常會在一個或多個層中構建應用程序。層是應用程序的高度耦合但相當獨立的組件。據加上在這，而不是服務，它被認為僅由一個應用程序使用的感覺。它獨立于如何不作為同一過程的一部分運行，甚至通常不在同一臺機器中運行。

讓我們用三個虛構的應用來說明這一點，當時任何大公司都會發展出來：

這些體系結構可能變得非常復雜，但總體而言，在不同的應用程序之間繪制線條非常容易，清楚地劃分出一個開始和另一個結束的位置。

當時，每個應用程序都有自己的數據副本和重復的常見業務流程實現。隨著時間的推移，隨著組織獲得或構建越來越多的應用程序，我們意識到我們需要不同的東西。我們需要應用程序來共享數據和重用邏輯，而我們曾經簡單的架構變得有點復雜：

隨著對更多重用和整合的需求，軟件行業的集體思維方式決定了一個非常抽象的概念，稱為服務。實際上，這意味著上面的圖表改為類似于此的東西：

上述架構的賣點是這些可重用服務提供的靈活性。理論上，在這個平臺上構建應用程序現在是一個問題：

選擇您需要的服務

寫一些調用這些服務的膠水代碼

將從中獲得的數據合并到最終用戶更熟悉的內容中

以最終用戶可以使用的方式呈現此數據

與此同時，計算機和互聯網正變得越來越流行。過去與職員或系統操作員交互的客戶開始直接與應用程序本身交互。設計思維和用戶體驗研究使我們擺脫了復雜的用戶界面，專注于讓專家用戶更高效地獲得更豐富，更實用的體驗，客戶可以理解這些體驗 - 沒有人閱讀網站手冊。更豐富的經驗需要豐富的數據，這意味著匯總來自各種來源的信息。

按照我們的示例，我們最終會得到如下圖所示的內容。

我們不再擁有業務線系統的用戶界面，而是越來越多的用戶界面本身就是應用程序。這些應用程序通常用JSP，PHP或ASP編寫，其代碼包含用戶界面和特定于應用程序的后端邏輯。

打破巨石

上面簡單的例子與許多現代技術組織的架構發展方式沒有什么不同。2011年，SoundCloud的網站如下所示：

Logic和All邏輯在一個地方。有一個系統，而這個系統是該應用程序。

如前一篇文章所述，我們發現此架構存在許多問題，并決定將邏輯提取到微服務中。盡管我們在提取后端服務方面取得了成功，但最長時間內母艦仍然處于每個請求的關鍵路徑上。

我們正在進行的架構改變背后的主要動機是縮短新功能的上市時間，我們發現我們最糟糕的瓶頸在于任何必須觸及整體的變化。考慮到用戶界面更改的頻率，從整體中提取代碼是一種提高生產力的直觀方法。然后，我們在其自己的組件中提取了我們的UI層，并使其從我們的公共API中獲取數據：

早在2011年，當這些架構發生變化時，絕大多數用戶都在網上。正如Fred Wilson所預測的那樣，最終這種情況發生了變化，我們的用戶群開始使用移動應用程序的方式比Web界面更頻繁。SoundCloud已經為Android和iOS提供了很長時間的移動客戶端，與我們的新Web應用程序類似，他們直接與我們的公共API進行了對話。

dogfooding帶來的挑戰

在現代軟件工程中，狗食通常被認為是一件好事。在我們自己的API之上構建我們的產品被認為是確保我們的API具有高質量并且始終是最新的最佳方式。在實踐中，我們遇到了這種方法的幾個問題。

我們的第一個問題不一定與技術有關，而是產品開發的根本挑戰。如果我們僅使用公共API，那么我們的平臺中沒有任何內容可供第三方API客戶端使用。盡管我們想要一個蓬勃發展的SoundCloud集成生態系統，但我們還是一家廣告公司，因此我們需要確保人們使用我們的屬性，而不僅僅是我們的數據。創建我們自己的應用程序獨有的功能意味著我們必須在許多地方不斷檢查OAuth范圍，并使人們很難欺騙我們的“官方應用程序”密鑰。

在一個更技術性的問題上，我們的公共API幾乎按照定義是非常通用的。為了使第三方開發人員能夠構建有趣的集成，您需要設計一個不會假設數據將如何使用的API。這會產生非常細粒度的端點，然后需要對多個不同端點的大量HTTP請求才能呈現最簡單的體驗。您可以在下面看到我們過去在整體時代提出的請求數量與我們為新的Web應用程序生成的請求數量：

要生成該單個配置文件頁面，我們必須對不同的API端點進行多次調用，例如：

• GET /tracks/1234.json?（該曲目的作者）
• GET /tracks/1234/related.json?（推薦相關的曲目）
• GET /users/86762.json?（關于該曲目的作者的信息）
• GET /users/me.json?（有關當前用戶的信息）
• ...

...然后，Web應用程序將合并以創建用戶配置文件頁面。雖然這個問題存在于所有平臺上，但對于我們不斷增長的移動用戶群來說，情況更糟，因為他們經常使用不可靠且速度慢的無線網絡

我們在上面的體系結構中遇到的第三個甚至更煩人的問題是，即使沒有整體結構，我們仍然存在API的瓶頸。每當團隊需要更改現有端點時，我們都需要確保更改不會破壞任何現有客戶端（包括重要的第三方集成）。每當我們添加新內容時，我們都需要投入大量時間來確保新端點不會過度專用于特定應用，所有客戶都可以輕松使用它們。所有這些協調使我們的日常工作變得比應有的困難，并使我們幾乎不可能進行A / B測試并減慢新功能的推出。

前端模式的后端（BFF）

在上述架構首次亮相近一年后，我們開始準備開發新的iOS應用程序。這是一個龐大的項目，最終會改變所有房產的用戶體驗。如此高風險，開發過程中的實驗和迭代至關重要。當工程團隊開始考慮應用程序的體系結構時，我們發現上述挑戰將成為項目的阻礙，我們需要重新思考我們的工作方式。

我們首先提出的解決方案是為移動和網絡提供不同的API。我們的想法是，讓客戶擁有API的團隊可以讓他們更快地移動，因為它不需要部件之間的協調。我們最初的想法是為不同的前端設置不同的后端。BFF一詞是由我們的網絡技術主管Nick Fisher創造的（我最初的建議是BEFFE，但我們講荷蘭語的隊友否決了這個選項）。

在它的第一個版本中，這些后端看起來仍然看起來像公共API，許多通用端點需要來自客戶端的許多調用來呈現單個屏幕。但是，隨著時間的推移，我們發現了一些有趣的事情。以用戶配置文件頁面為例，以前這是一個僅存在于客戶端的概念。Web或移動應用程序將從各個端點獲取數據，并使用它來創建我們稱為用戶配置文件的對象。這是一個特定于應用程序的對象。

在某些時候，我們的客戶團隊意識到，由于他們擁有API，他們可以將這個對象推向API。他們可以提取所有調用不同服務的邏輯，并將它們一起混合到后端的用戶配置文件中。

這最終將簡化代碼并提高性能。不是對上面描述的多個端點進行多個不同的調用，而是需要請求的所有客戶端都是單個資源：

• GET /user-profile/123.json

當我們進一步嘗試這個模型時，我們發現自己在BFF中編寫了很多演示模型。在這個階段，我們意識到BFF不是應用程序使用的API?。BFF是申請的一部分。

最終，我們的所有屬性（包括API）都開始遵循此模式。

一直往下

在某些時候，我們生產了大約五種不同的BFF，我們已經開始研究如何進一步提高生產率。接下來是我們的用戶配置文件示例，對我們來說顯而易見的是，鑒于每個應用程序都有一個等效的用戶配置文件頁面，所有BFF都有很多重復的代碼來獲取和合并它們的數據。

復制并不準確，像網絡瀏覽器這樣的大屏幕在其用戶個人資料頁面上的信息要比微型移動應用程序多得多。然而，我們看到重復是一種難聞的氣味，表明我們在域模型中缺少一個對象。為了解決這個問題，我們創建了一個UserProfileService處理這個重復邏輯的方法。

隨著時間的推移，我們發現了越來越多這樣的情況。我們開始有意識地轉向一個架構，在這個架構中，用戶理解的大多數核心對象都有自己的微服務支持它們。

轉載于:https://www.cnblogs.com/BlogNetSpace/p/4866748.html

總結

以上是生活随笔為你收集整理的架构设计系列-前端模式的后端（BFF）翻译PhilCalçado的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。