核心要點(diǎn)

• GraphQL網(wǎng)關(guān)融合了傳統(tǒng)API網(wǎng)關(guān)和GraphQL的優(yōu)勢，使軟件工程師能夠從多個(gè)數(shù)據(jù)源獲取數(shù)據(jù)，同時(shí)保持前端效率。
• 後端即前端(BFF)架構(gòu)模式減少了前端的請求數(shù)量，通過允許向API網(wǎng)關(guān)發(fā)出單個(gè)請求來簡化流程，然後API網(wǎng)關(guān)從每個(gè)後端服務(wù)獲取數(shù)據(jù)並將其組合起來。
• GraphQL為BFF提供了諸多優(yōu)勢，包括高效的數(shù)據(jù)獲取、所有請求的單一端點(diǎn)以及允許前端為每個(gè)請求僅選擇所需數(shù)據(jù)的靈活查詢。
• 建立GraphQL網(wǎng)關(guān)的三個(gè)推薦框架包括Hasura、StepZen和Graphweaver。這些框架提供了多種功能，例如多個(gè)數(shù)據(jù)源連接、路由、批處理、安全、跨數(shù)據(jù)源過濾和可擴(kuò)展性。

本文將討論如何從多個(gè)數(shù)據(jù)源獲取數(shù)據(jù)，同時(shí)保持前端快速響應(yīng)的問題，以及一個(gè)潛在的解決方案：使用GraphQL網(wǎng)關(guān)。

作為軟件工程師，我們都面臨著將來自多個(gè)系統(tǒng)的數(shù)據(jù)組合在一起的挑戰(zhàn)。即使是單個(gè)頁面也需要來自多個(gè)服務(wù)的數(shù)據(jù)才能呈現(xiàn)。

數(shù)據(jù)無處不在，從CRM到金融系統(tǒng)，從SaaS平臺到數(shù)據(jù)庫。每個(gè)企業(yè)不可避免地會購買大量的SaaS平臺，然後希望在所有這些平臺之上獲得統(tǒng)一的業(yè)務(wù)視圖。我們必須直面這個(gè)問題，並將所有內(nèi)容整合起來。

GraphQL網(wǎng)關(guān)結(jié)合了傳統(tǒng)API網(wǎng)關(guān)和GraphQL的優(yōu)勢。

我們將首先討論API網(wǎng)關(guān)的優(yōu)勢，然後看看GraphQL是如何融入其中的。請繼續(xù)閱讀本文，我們將介紹一些構(gòu)建我們自己的API網(wǎng)關(guān)的框架。

API網(wǎng)關(guān)的優(yōu)勢

保護(hù)面向公眾的API免受黑客攻擊是一項(xiàng)全天候的工作。隨著時(shí)間的推移，組織已經(jīng)發(fā)展到創(chuàng)建許多API，從面向服務(wù)的架構(gòu)到微服務(wù)。組織更傾向於添加一個(gè)額外的安全層，而不是將這些API直接放在互聯(lián)網(wǎng)上，該安全層位於所有這些API的前面，並確保對數(shù)據(jù)的訪問始終遵循相同的身份驗(yàn)證規(guī)則。

他們使用API網(wǎng)關(guān)來做到這一點(diǎn)。

Kong或Apigee等產(chǎn)品從中心位置公開內(nèi)部API。它們充當(dāng)反向代理，具有API密鑰管理、速率限制和監(jiān)控等功能。

API網(wǎng)關(guān)允許我們控制誰以及什麼可以訪問每個(gè)服務(wù)，監(jiān)控連接和記錄訪問。

最近，應(yīng)用程序需要將數(shù)據(jù)從API網(wǎng)關(guān)和其他外部SaaS提供商組合起來。這意味著舊的集中式工具（確保我們的規(guī)則得到遵守）現(xiàn)在定期被繞過。

假設(shè)我們正在為公司構(gòu)建一個(gè)Web應(yīng)用程序。我們的任務(wù)是創(chuàng)建用戶個(gè)人資料頁面。在登錄過程中，我們需要組合來自多個(gè)系統(tǒng)的數(shù)據(jù)：

• Salesforce CRM：保存一般的客戶數(shù)據(jù)，例如名字和姓氏。
• 訂單：最近的訂單位於組織內(nèi)的訂單系統(tǒng)中。
• 通知服務(wù)：通知設(shè)置和最近的消息位於連接到Node.js服務(wù)的特定於應(yīng)用程序的數(shù)據(jù)庫中。

客戶端需要發(fā)出三個(gè)單獨(dú)的請求才能獲取數(shù)據(jù)，如下圖所示。

在上圖中，Web客戶端發(fā)送三個(gè)單獨(dú)的API請求，然後必須在前端代碼中組合結(jié)果。發(fā)送多個(gè)請求會影響應(yīng)用程序的性能，並且組合這些數(shù)據(jù)會增加代碼的複雜性。此外，如果有多個(gè)應(yīng)用程序，現(xiàn)在所有應(yīng)用程序都必須了解所有後端，並且一個(gè)服務(wù)中的單個(gè)API更改可能會導(dǎo)致我們所有應(yīng)用程序的更新。

我們可以做得更好。理想情況下，我們希望將請求從三個(gè)減少到一個(gè)。我們可以創(chuàng)建一個(gè)新服務(wù)來執(zhí)行此操作——一個(gè)協(xié)調(diào)對後端服務(wù)請求的服務(wù)。這個(gè)想法有一個(gè)名稱：BFF模式。

後端即前端(BFF)架構(gòu)模式允許前端發(fā)出單個(gè)請求。

但它是如何工作的呢？讓我們更詳細(xì)地了解一下這種模式。

BFF模式的優(yōu)勢

使用BFF模式，應(yīng)用程序向API網(wǎng)關(guān)發(fā)送單個(gè)請求。然後，BFF服務(wù)向每個(gè)後端服務(wù)請求數(shù)據(jù)並將其組合起來。最後，對數(shù)據(jù)進(jìn)行過濾，只返回前端所需的數(shù)據(jù)，從而減少通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。

如上圖所示，我們在堆棧中引入了一個(gè)額外的層來協(xié)調(diào)請求。

用戶個(gè)人資料端點(diǎn)返回該應(yīng)用程序在個(gè)人資料頁面上所需的的數(shù)據(jù)。將我們的三個(gè)請求減少到一個(gè)請求已經(jīng)解決了我們之前的性能問題。

但我們還沒有完成。

企業(yè)決定發(fā)布一個(gè)移動應(yīng)用程序。移動應(yīng)用程序也有一個(gè)個(gè)人資料頁面，但此屏幕顯示的個(gè)人資料信息要少得多。

此時(shí)，移動團(tuán)隊(duì)有兩個(gè)選擇。該團(tuán)隊(duì)可以使用Web團(tuán)隊(duì)的端點(diǎn)，這意味著我們會過度獲取數(shù)據(jù)（獲取移動應(yīng)用程序不需要的更多數(shù)據(jù)）。另一種選擇是移動團(tuán)隊(duì)創(chuàng)建自己的BFF。

不出所料，移動團(tuán)隊(duì)決定創(chuàng)建自己的BFF，因?yàn)樗麄兿Ｍ麨樗麄兊膽?yīng)用程序獲得良好的性能。

如上圖所示，事情開始變得複雜起來，我們現(xiàn)在有兩個(gè)新問題：

• 每個(gè)團(tuán)隊(duì)都必須為他們創(chuàng)建的每個(gè)應(yīng)用程序創(chuàng)建一個(gè)新的BFF服務(wù)，這會減慢每個(gè)團(tuán)隊(duì)的速度，並使其難以標(biāo)準(zhǔn)化。
• 每個(gè)BFF都需要進(jìn)行滲透測試以確保其安全。

我們?nèi)绾谓鉀Q這些問題？

我們需要一個(gè)解決方案，讓每個(gè)應(yīng)用程序都可以選擇它需要的數(shù)據(jù)，並且它應(yīng)該是公司所有應(yīng)用程序使用的單個(gè)API。

隨著BFF的成熟，許多開發(fā)人員已經(jīng)開始嘗試使用GraphQL而不是REST。

讓我們看看這項(xiàng)技術(shù)如何提供幫助。

GraphQL對BFF的優(yōu)勢

GraphQL具有許多使其成為BFF理想技術(shù)的優(yōu)勢：

• 高效的數(shù)據(jù)獲取。 GraphQL使客戶端能夠準(zhǔn)確請求所需的數(shù)據(jù)，不多不少。這通過減少從API傳輸?shù)臄?shù)據(jù)來提高性能。
• 單一端點(diǎn)。 GraphQL不是通過網(wǎng)關(guān)公開許多端點(diǎn)，而是對所有請求使用單個(gè)端點(diǎn)。這簡化了維護(hù)和版本控制的需要。
• 靈活的查詢?？蛻舳丝梢酝ㄟ^將字段和關(guān)係組合到單個(gè)請求中來構(gòu)建查詢。這使前端開發(fā)人員能夠優(yōu)化數(shù)據(jù)獲取，從而提高性能。此外，如果前端的要求發(fā)生變化，可以更新它以獲取不同的數(shù)據(jù)，而無需以任何方式更改後端。

前端現(xiàn)在可以為每個(gè)請求只選擇所需的數(shù)據(jù)。

我們現(xiàn)在可以將我們的兩個(gè)應(yīng)用程序連接到同一個(gè)GraphQL服務(wù)器，從而減少對第二個(gè)BFF服務(wù)的需要。

我們現(xiàn)在可以為組織中的任何應(yīng)用程序共享BFF。我們還有一個(gè)需要進(jìn)行滲透測試的單一端點(diǎn)。

但是，我們又引入了一個(gè)新問題！我們?nèi)匀槐仨毠芾韮蓚€(gè)系統(tǒng)——API網(wǎng)關(guān)和GraphQL BFF。

如果我們將兩者合併到一個(gè)GraphQL網(wǎng)關(guān)中會怎樣？

接下來，讓我們看看GraphQL網(wǎng)關(guān)是如何工作的。

什麼是GraphQL網(wǎng)關(guān)？

GraphQL網(wǎng)關(guān)將API網(wǎng)關(guān)與GraphQL API結(jié)合起來，以獲得這兩種技術(shù)的最佳效果。

讓我們回顧一下優(yōu)勢：

• 開發(fā)人員擁有一個(gè)單一的API端點(diǎn)來請求數(shù)據(jù)。這減少了過度或不足的獲取，因?yàn)槊總€(gè)應(yīng)用程序只選擇它需要的數(shù)據(jù)。
• GraphQL網(wǎng)關(guān)由組織中的許多應(yīng)用程序共享。這意味著我們已將安全風(fēng)險(xiǎn)降低到單個(gè)API端點(diǎn)。
• 我們現(xiàn)在只有一個(gè)服務(wù)需要管理和部署，因?yàn)锽FF與網(wǎng)關(guān)合併了。

下圖顯示了用戶個(gè)人資料API請求如何與GraphQL網(wǎng)關(guān)一起工作。

在上圖中，客戶端向GraphQL網(wǎng)關(guān)發(fā)送單個(gè)請求，請求其所需的數(shù)據(jù)。網(wǎng)關(guān)向每個(gè)服務(wù)發(fā)出單個(gè)請求並組合結(jié)果。我們現(xiàn)在只有一個(gè)服務(wù)需要管理和部署。

希望您已準(zhǔn)備好自己嘗試一下。接下來，讓我們看看如何構(gòu)建GraphQL網(wǎng)關(guān)。

構(gòu)建GraphQL網(wǎng)關(guān)

在選擇網(wǎng)關(guān)框架時(shí)，我們需要尋找一些關(guān)鍵功能：

• 多個(gè)數(shù)據(jù)源。網(wǎng)關(guān)必須連接到許多數(shù)據(jù)源——從數(shù)據(jù)庫到SaaS——我們應(yīng)該能夠創(chuàng)建我們的連接。
• 路由。網(wǎng)關(guān)應(yīng)該能夠直接從底層服務(wù)請求數(shù)據(jù)。
• 批處理。發(fā)送到同一服務(wù)的多個(gè)查詢以批處理方式發(fā)送，從而減少請求數(shù)量。
• 安全。身份驗(yàn)證和授權(quán)應(yīng)控制誰可以訪問連接的數(shù)據(jù)。
• 跨數(shù)據(jù)源過濾。應(yīng)該提供強(qiáng)大的過濾器以避免過度獲取客戶端所需的數(shù)據(jù)。
• 可擴(kuò)展性。開發(fā)人員應(yīng)該能夠使用中間件或函數(shù)擴(kuò)展代碼以滿足他們的需求。

有很多框架可供選擇，但我推薦進(jìn)一步探索以下三個(gè)框架。

Hasura

Hasura 這些年來越來越受歡迎，最初是作為GraphQL-over-Postgres服務(wù)器。但是，它增加了連接到外部系統(tǒng)的能力。

我們可以連接一個(gè)“遠(yuǎn)程模式”，它結(jié)合了來自其他服務(wù)器的GraphQL。

這種方法有一些缺點(diǎn)。首先，我們需要在一個(gè)單獨(dú)的服務(wù)中創(chuàng)建和管理我們的遠(yuǎn)程模式，並且此服務(wù)必須是GraphQL端點(diǎn)。這導(dǎo)致了第二個(gè)問題：我們無法直接連接數(shù)據(jù)源。

此外，Hasura不允許我們根據(jù)另一個(gè)數(shù)據(jù)源中的值來過濾一個(gè)數(shù)據(jù)源中的數(shù)據(jù)。這聽起來可能很學(xué)術(shù)，但實(shí)際上我們經(jīng)常想要表達(dá)類似“給我客戶名稱為‘ABC’的訂單”這樣的內(nèi)容。

這提供了靈活性，但代價(jià)是運(yùn)行多個(gè)服務(wù)。讓我們看看一個(gè)可以直接連接的選項(xiàng)。

StepZen

StepZen允許我們直接從GraphQL服務(wù)器連接到數(shù)據(jù)源。這減少了運(yùn)行多個(gè)服務(wù)以創(chuàng)建網(wǎng)關(guān)的需要。

要將Stepzen連接到數(shù)據(jù)源，我們創(chuàng)建如下所示的GraphQL模式文件：

<code>type Query {
  anything(message: String): JSON
  @rest (
    endpoint: "https://httpbin.org/anything"
    method: POST
    headers: [
      {name: "User-Agent", value: "StepZen"}
      {name: "X-Api-Key", value: "12345"}
    ]
    postbody: """
      {
        "user": {
          "id": "1000",
          "name": "The User"
         }
      }
    """
    )
}
</code>

在這個(gè)例子中，我們使用自定義模式將服務(wù)器連接到數(shù)據(jù)庫。

還有另一個(gè)您可能更喜歡的選項(xiàng)，那就是純代碼方法。讓我們接下來看看。

Graphweaver

在過去的幾年裡，我一直在開發(fā)一個(gè)名為Graphweaver的開源產(chǎn)品，它可以用作GraphQL網(wǎng)關(guān)。

它直接連接到我們的數(shù)據(jù)源並創(chuàng)建一個(gè)即時(shí)的GraphQL API。此API包含我們可能期望創(chuàng)建、讀取、更新和刪除的所有CRUD操作。它自動生成過濾器、排序和分頁參數(shù)，從而節(jié)省時(shí)間。我們可以用我們的代碼擴(kuò)展內(nèi)置操作以實(shí)現(xiàn)完全的靈活性。

Graphweaver 為 Postgres 和 Mysql 等數(shù)據(jù)庫以及 Xero 和 Contentful 等 SaaS 提供商提供了開箱即用的數(shù)據(jù)連接器。

進(jìn)行更改或連接數(shù)據(jù)源涉及編寫 Typescript 代碼，從而使我們能夠進(jìn)行完全自定義。

如果您有興趣創(chuàng)建自己的GraphQL API，我強(qiáng)烈建議您查看Graphweaver GitHub代碼。

結(jié)論

在本文中，我們研究瞭如何用單個(gè)GraphQL網(wǎng)關(guān)替換我們當(dāng)前的API網(wǎng)關(guān)和BFF模式。

我們研究了API網(wǎng)關(guān)的優(yōu)勢以及組織使用它們的原因。版本控制、速率限制和訪問管理是一些原因。

我們還研究了BFF模式以及它如何為前端應(yīng)用程序協(xié)調(diào)API請求。

最後，我們研究了GraphQL以及為什麼它對BFF來說是一項(xiàng)有益的技術(shù)。

最終，這導(dǎo)致我們創(chuàng)建了一個(gè)GraphQL網(wǎng)關(guān)，我們研究了創(chuàng)建我們自己的三個(gè)選項(xiàng)：Hasura、StepZen和我一直在開發(fā)的產(chǎn)品Graphweaver。

我希望本文能說服您嘗試自己使用GraphQL網(wǎng)關(guān)，如果可以的話，請考慮嘗試Graphweaver。

GraphQL網(wǎng)關(guān)常見問題解答(FAQ)

GraphQL網(wǎng)關(guān)的主要用途是什麼？

GraphQL網(wǎng)關(guān)充當(dāng)所有GraphQL操作的單一入口點(diǎn)。它負(fù)責(zé)將請求路由到相應(yīng)的服務(wù)，聚合響應(yīng)並將它們發(fā)送回客戶端。這使您可以從單個(gè)位置管理多個(gè)GraphQL模式和服務(wù)，從而使您的應(yīng)用程序更具可擴(kuò)展性和易於維護(hù)。

GraphQL網(wǎng)關(guān)與傳統(tǒng)的API網(wǎng)關(guān)有何不同？

傳統(tǒng)的API網(wǎng)關(guān)旨在處理RESTful API，其運(yùn)行模式與GraphQL不同。另一方面，GraphQL網(wǎng)關(guān)專門設(shè)計(jì)用於處理GraphQL操作。它提供諸如模式拼接和合併之類的功能，這些功能允許您將多個(gè)GraphQL模式組合成一個(gè)。這是傳統(tǒng)API網(wǎng)關(guān)無法做到的。

GraphQL網(wǎng)關(guān)中的模式拼接是什麼？

模式拼接是GraphQL網(wǎng)關(guān)的一項(xiàng)功能，允許您將多個(gè)GraphQL模式組合成一個(gè)。當(dāng)您有多個(gè)服務(wù)且每個(gè)服務(wù)都有自己的模式，並且您想將它們公開為單個(gè)API時(shí)，這特別有用。模式拼接負(fù)責(zé)合併模式並解決任何衝突，為客戶端提供無縫的體驗(yàn)。

GraphQL網(wǎng)關(guān)如何提高性能？

GraphQL網(wǎng)關(guān)可以通過減少客戶端和服務(wù)器之間的往返次數(shù)來顯著提高性能?？蛻舳藷o需向不同的服務(wù)發(fā)出多個(gè)請求，而只需向GraphQL網(wǎng)關(guān)發(fā)出單個(gè)請求，然後網(wǎng)關(guān)將請求路由到相應(yīng)的服務(wù)，聚合響應(yīng)並將它們發(fā)送回客戶端。這減少了網(wǎng)絡(luò)延遲並提高了整體性能。

我可以在微服務(wù)中使用GraphQL網(wǎng)關(guān)嗎？

是的，GraphQL網(wǎng)關(guān)特別適合微服務(wù)架構(gòu)。每個(gè)微服務(wù)都可以有自己的GraphQL模式，網(wǎng)關(guān)可以將這些模式拼接在一起以提供統(tǒng)一的API。這允許您獨(dú)立管理和擴(kuò)展微服務(wù)，同時(shí)仍然為您的客戶端提供一致的接口。

GraphQL網(wǎng)關(guān)與所有編程語言兼容嗎？

GraphQL網(wǎng)關(guān)與語言無關(guān)，這意味著它可以與任何支持GraphQL的編程語言一起使用。這包括JavaScript、Python、Ruby和Java等流行語言。

GraphQL網(wǎng)關(guān)如何處理錯(cuò)誤？

GraphQL網(wǎng)關(guān)提供強(qiáng)大的錯(cuò)誤處理功能。如果其中一項(xiàng)服務(wù)發(fā)生錯(cuò)誤，網(wǎng)關(guān)將向客戶端返回詳細(xì)的錯(cuò)誤消息，包括有關(guān)哪個(gè)服務(wù)導(dǎo)致錯(cuò)誤以及發(fā)生了什麼錯(cuò)誤的信息。這使得診斷和修復(fù)問題更容易。

我可以在無服務(wù)器架構(gòu)中使用GraphQL網(wǎng)關(guān)嗎？

是的，GraphQL網(wǎng)關(guān)與無服務(wù)器架構(gòu)兼容。您可以將網(wǎng)關(guān)部署為無服務(wù)器函數(shù)，這使您可以利用無服務(wù)器計(jì)算的可擴(kuò)展性和成本效益。

GraphQL網(wǎng)關(guān)如何處理安全？

GraphQL網(wǎng)關(guān)提供多種安全功能，包括身份驗(yàn)證和授權(quán)、速率限制和請求驗(yàn)證。這些功能有助於保護(hù)您的服務(wù)免受未經(jīng)授權(quán)的訪問和濫用。

我可以將GraphQL網(wǎng)關(guān)與現(xiàn)有的RESTful API一起使用嗎？

是的，您可以將GraphQL網(wǎng)關(guān)與現(xiàn)有的RESTful API一起使用。網(wǎng)關(guān)可以在GraphQL模式中包裝您的RESTful API，允許您在仍然使用現(xiàn)有API的同時(shí)利用GraphQL的優(yōu)勢。

以上是構(gòu)建GraphQl網(wǎng)關(guān)：組合，針跡或合併任何數(shù)據(jù)源的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！