構建GraphQl網關：組合，針跡或合併任何數據源

核心要點

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

本文將討論如何從多個數據源獲取數據，同時保持前端快速響應的問題，以及一個潛在的解決方案：使用GraphQL網關。

作為軟件工程師，我們都面臨著將來自多個系統的數據組合在一起的挑戰。即使是單個頁面也需要來自多個服務的數據才能呈現。

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

GraphQL網關結合了傳統API網關和GraphQL的優勢。

我們將首先討論API網關的優勢，然後看看GraphQL是如何融入其中的。請繼續閱讀本文，我們將介紹一些構建我們自己的API網關的框架。

API網關的優勢

保護面向公眾的API免受黑客攻擊是一項全天候的工作。隨著時間的推移，組織已經發展到創建許多API，從面向服務的架構到微服務。組織更傾向於添加一個額外的安全層，而不是將這些API直接放在互聯網上，該安全層位於所有這些API的前面，並確保對數據的訪問始終遵循相同的身份驗證規則。

他們使用API網關來做到這一點。

Kong或Apigee等產品從中心位置公開內部API。它們充當反向代理，具有API密鑰管理、速率限制和監控等功能。

API網關允許我們控制誰以及什麼可以訪問每個服務，監控連接和記錄訪問。

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

假設我們正在為公司構建一個Web應用程序。我們的任務是創建用戶個人資料頁面。在登錄過程中，我們需要組合來自多個系統的數據：

• Salesforce CRM：保存一般的客戶數據，例如名字和姓氏。
• 訂單：最近的訂單位於組織內的訂單系統中。
• 通知服務：通知設置和最近的消息位於連接到Node.js服務的特定於應用程序的數據庫中。

客戶端需要發出三個單獨的請求才能獲取數據，如下圖所示。

在上圖中，Web客戶端發送三個單獨的API請求，然後必須在前端代碼中組合結果。發送多個請求會影響應用程序的性能，並且組合這些數據會增加代碼的複雜性。此外，如果有多個應用程序，現在所有應用程序都必須了解所有後端，並且一個服務中的單個API更改可能會導致我們所有應用程序的更新。

我們可以做得更好。理想情況下，我們希望將請求從三個減少到一個。我們可以創建一個新服務來執行此操作——一個協調對後端服務請求的服務。這個想法有一個名稱：BFF模式。

後端即前端(BFF)架構模式允許前端發出單個請求。

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

BFF模式的優勢

使用BFF模式，應用程序向API網關發送單個請求。然後，BFF服務向每個後端服務請求數據並將其組合起來。最後，對數據進行過濾，只返回前端所需的數據，從而減少通過網絡傳輸的數據量。

如上圖所示，我們在堆棧中引入了一個額外的層來協調請求。

用戶個人資料端點返回該應用程序在個人資料頁面上所需的的數據。將我們的三個請求減少到一個請求已經解決了我們之前的性能問題。

但我們還沒有完成。

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

此時，移動團隊有兩個選擇。該團隊可以使用Web團隊的端點，這意味著我們會過度獲取數據（獲取移動應用程序不需要的更多數據）。另一種選擇是移動團隊創建自己的BFF。

不出所料，移動團隊決定創建自己的BFF，因為他們希望為他們的應用程序獲得良好的性能。

如上圖所示，事情開始變得複雜起來，我們現在有兩個新問題：

• 每個團隊都必須為他們創建的每個應用程序創建一個新的BFF服務，這會減慢每個團隊的速度，並使其難以標準化。
• 每個BFF都需要進行滲透測試以確保其安全。

我們如何解決這些問題？

我們需要一個解決方案，讓每個應用程序都可以選擇它需要的數據，並且它應該是公司所有應用程序使用的單個API。

隨著BFF的成熟，許多開發人員已經開始嘗試使用GraphQL而不是REST。

讓我們看看這項技術如何提供幫助。

GraphQL對BFF的優勢

GraphQL具有許多使其成為BFF理想技術的優勢：

• 高效的數據獲取。 GraphQL使客戶端能夠準確請求所需的數據，不多不少。這通過減少從API傳輸的數據來提高性能。
• 單一端點。 GraphQL不是通過網關公開許多端點，而是對所有請求使用單個端點。這簡化了維護和版本控制的需要。
• 靈活的查詢。客戶端可以通過將字段和關係組合到單個請求中來構建查詢。這使前端開發人員能夠優化數據獲取，從而提高性能。此外，如果前端的要求發生變化，可以更新它以獲取不同的數據，而無需以任何方式更改後端。

前端現在可以為每個請求只選擇所需的數據。

我們現在可以將我們的兩個應用程序連接到同一個GraphQL服務器，從而減少對第二個BFF服務的需要。

我們現在可以為組織中的任何應用程序共享BFF。我們還有一個需要進行滲透測試的單一端點。

但是，我們又引入了一個新問題！我們仍然必須管理兩個系統——API網關和GraphQL BFF。

如果我們將兩者合併到一個GraphQL網關中會怎樣？

接下來，讓我們看看GraphQL網關是如何工作的。

什麼是GraphQL網關？

GraphQL網關將API網關與GraphQL API結合起來，以獲得這兩種技術的最佳效果。

讓我們回顧一下優勢：

• 開發人員擁有一個單一的API端點來請求數據。這減少了過度或不足的獲取，因為每個應用程序只選擇它需要的數據。
• GraphQL網關由組織中的許多應用程序共享。這意味著我們已將安全風險降低到單個API端點。
• 我們現在只有一個服務需要管理和部署，因為BFF與網關合併了。

下圖顯示了用戶個人資料API請求如何與GraphQL網關一起工作。

在上圖中，客戶端向GraphQL網關發送單個請求，請求其所需的數據。網關向每個服務發出單個請求並組合結果。我們現在只有一個服務需要管理和部署。

希望您已準備好自己嘗試一下。接下來，讓我們看看如何構建GraphQL網關。

構建GraphQL網關

在選擇網關框架時，我們需要尋找一些關鍵功能：

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

有很多框架可供選擇，但我推薦進一步探索以下三個框架。

Hasura

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

我們可以連接一個“遠程模式”，它結合了來自其他服務器的GraphQL。

這種方法有一些缺點。首先，我們需要在一個單獨的服務中創建和管理我們的遠程模式，並且此服務必須是GraphQL端點。這導致了第二個問題：我們無法直接連接數據源。

此外，Hasura不允許我們根據另一個數據源中的值來過濾一個數據源中的數據。這聽起來可能很學術，但實際上我們經常想要表達類似“給我客戶名稱為‘ABC’的訂單”這樣的內容。

這提供了靈活性，但代價是運行多個服務。讓我們看看一個可以直接連接的選項。

StepZen

StepZen允許我們直接從GraphQL服務器連接到數據源。這減少了運行多個服務以創建網關的需要。

要將Stepzen連接到數據源，我們創建如下所示的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>

在這個例子中，我們使用自定義模式將服務器連接到數據庫。

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

Graphweaver

在過去的幾年裡，我一直在開發一個名為Graphweaver的開源產品，它可以用作GraphQL網關。

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

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

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

如果您有興趣創建自己的GraphQL API，我強烈建議您查看Graphweaver GitHub代碼。

結論

在本文中，我們研究瞭如何用單個GraphQL網關替換我們當前的API網關和BFF模式。

我們研究了API網關的優勢以及組織使用它們的原因。版本控制、速率限制和訪問管理是一些原因。

我們還研究了BFF模式以及它如何為前端應用程序協調API請求。

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

最終，這導致我們創建了一個GraphQL網關，我們研究了創建我們自己的三個選項：Hasura、StepZen和我一直在開發的產品Graphweaver。

我希望本文能說服您嘗試自己使用GraphQL網關，如果可以的話，請考慮嘗試Graphweaver。

GraphQL網關常見問題解答(FAQ)

GraphQL網關的主要用途是什麼？

GraphQL網關充當所有GraphQL操作的單一入口點。它負責將請求路由到相應的服務，聚合響應並將它們發送回客戶端。這使您可以從單個位置管理多個GraphQL模式和服務，從而使您的應用程序更具可擴展性和易於維護。

GraphQL網關與傳統的API網關有何不同？

傳統的API網關旨在處理RESTful API，其運行模式與GraphQL不同。另一方面，GraphQL網關專門設計用於處理GraphQL操作。它提供諸如模式拼接和合併之類的功能，這些功能允許您將多個GraphQL模式組合成一個。這是傳統API網關無法做到的。

GraphQL網關中的模式拼接是什麼？

模式拼接是GraphQL網關的一項功能，允許您將多個GraphQL模式組合成一個。當您有多個服務且每個服務都有自己的模式，並且您想將它們公開為單個API時，這特別有用。模式拼接負責合併模式並解決任何衝突，為客戶端提供無縫的體驗。

GraphQL網關如何提高性能？

GraphQL網關可以通過減少客戶端和服務器之間的往返次數來顯著提高性能。客戶端無需向不同的服務發出多個請求，而只需向GraphQL網關發出單個請求，然後網關將請求路由到相應的服務，聚合響應並將它們發送回客戶端。這減少了網絡延遲並提高了整體性能。

我可以在微服務中使用GraphQL網關嗎？

是的，GraphQL網關特別適合微服務架構。每個微服務都可以有自己的GraphQL模式，網關可以將這些模式拼接在一起以提供統一的API。這允許您獨立管理和擴展微服務，同時仍然為您的客戶端提供一致的接口。

GraphQL網關與所有編程語言兼容嗎？

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

GraphQL網關如何處理錯誤？

GraphQL網關提供強大的錯誤處理功能。如果其中一項服務發生錯誤，網關將向客戶端返回詳細的錯誤消息，包括有關哪個服務導致錯誤以及發生了什麼錯誤的信息。這使得診斷和修復問題更容易。

我可以在無服務器架構中使用GraphQL網關嗎？

是的，GraphQL網關與無服務器架構兼容。您可以將網關部署為無服務器函數，這使您可以利用無服務器計算的可擴展性和成本效益。

GraphQL網關如何處理安全？

GraphQL網關提供多種安全功能，包括身份驗證和授權、速率限制和請求驗證。這些功能有助於保護您的服務免受未經授權的訪問和濫用。

我可以將GraphQL網關與現有的RESTful API一起使用嗎？

是的，您可以將GraphQL網關與現有的RESTful API一起使用。網關可以在GraphQL模式中包裝您的RESTful API，允許您在仍然使用現有API的同時利用GraphQL的優勢。

以上是構建GraphQl網關：組合，針跡或合併任何數據源的詳細內容。更多資訊請關注PHP中文網其他相關文章！