Hasura GraphQL Engine for Dynamic APIs with PostgreSQL 簡介

一般來說，在過去的幾年裡，REST API 在處理快速變化的技術需求時一直受到批評，因為它不夠靈活。 回想起來，許多人認為 GraphQL 的創建是為了滿足 API 開發對額外靈活性和效率的需求。 因此，減輕了 REST API 的缺陷。 由於 Facebook 從 HTML5 應用程序過渡到更強大和更原生的設置，GraphQL 在過去五年中越來越受歡迎和採用，這是有充分理由的。 在這篇博客中，我們將深入研究 GraphQL 現象，PostgreSQL 以及稍後對 Hasura GraphQL 引擎的全面介紹。 在一個片段中，Hasura GraphQL 引擎-PostgreSQL 關係和生態系統。

GraphQL：Facebook 的叛亂

儘管許多人認為 GraphQL 是作為對 REST API 的反叛而創建的，但這可能與事實相去甚遠。 具有諷刺意味的是，它的創建只是為了滿足 Facebook 的內部需求。 最初由 Facebook 團隊設計和開源，GraphQL 經常被混淆為一種數據庫技術。 從本質上講，儘管存在誤解，但 GraphQL 在技術上是一種用於 API 而非數據庫的查詢語言。 因此，它降低了構建 API 的複雜性，將所有請求抽像到單個端點。 與傳統的 REST API 不同，GraphQL 是聲明性的，這意味著無論請求什麼都會返回。 儘管為了獲得更多上下文，我們需要退後一步，重新審視 REST API。

REST 架構

通常，API 是指定軟件組件應如何交互的規則、例程或協議。 Representational State Transfer (REST) 基本上是一種 API 設計架構，通常在 Web 服務的實現中使用，其中一切都被視為“資源”。 不幸的是，RESTful 方法一直局限於處理單一資源。 因此，如果需要數據並且來自兩個或更多資源，例如帖子和用戶，則需要多次往返服務器以收集所需的一切。 此外，REST 面臨“過度”和“不足”獲取的問題。 所有這一切都不理想，尤其是隨著更多數據驅動的應用程序的出現，這些應用程序處理結合了相關資源的大型數據集。 這可以解釋 Facebook 面臨的困境。

因此，需要採用更靈活和漸進的方法的 API 架構。

創造另一種選擇

或者， GraphQL 不會根據資源 URL、輔助鍵或表來考慮數據，而是根據對像圖和使用NSObjects或JSON 的模型來考慮數據。 具體來說，GraphQL 不需要每個用例的專用端點，因為不同的功能和用例可以在單個“圖形”中表示。 使用 GraphQL 查詢語言，您可以準確描述響應應該是什麼樣子，因此不需要額外的服務器往返。 作為一種應用層查詢語言，它旨在解釋來自服務器/客戶端的字符串，並以穩定、可理解和可預測的格式返回該數據。 它只是一個更好地整合數據的工具。

簡單、穩定和高效。

事實是，並非所有項目都需要 GraphQL，儘管它定義明確的模式，所以我們確信我們不會過度獲取。 但是，如果我們的企業產品依賴於來自多個來源的數據，例如 MySQL、Postgres 和其他 API，那麼 GraphQL 是更好的選擇。 GraphQL 以簡單而自豪，尤其是在數據檢索方面，因為數據是在一個公共端點或調用下收集的。 本質上，由於客戶端得到了他們真正需要的東西，這有效地減少了客戶端發出的每個請求的大小，從而產生高性能的應用程序。 由於 GraphQL 統一了原本需要多個端點的數據，因此它簡化了複雜的重複檢索，從而提高了查詢效率。 因此，隨著時間的推移，它的簡單性帶來了更多的後端穩定性、規劃、構建、執行和持續運行。

GraphQL 的優勢

簡而言之，GraphQL 允許通過易於理解的查詢來提取數據，允許快速開發輕量級和快速的應用程序，因為數據可以更直接地訪問而不是通過服務器。 此外，它允許通過一個查詢檢索多個資源，而無需使用多個 URL 或資源鏈，同時對所有數據使用一個端點。 請記住，數據是使用基於圖形的方案在服務器上定義的，因此作為一個包而不是通過多次調用交付。 這允許在 API 開發期間聚合 API 響應的操作提升。

這反過來又減輕了前端開發團隊的負擔，促進了 API 版本控制，簡化了維護，並節省了數據傳輸需求。 此外，它在接收數據時允許更多的可預測性，支持聲明性數據獲取並減輕過度獲取和獲取不足。 本質上，當客戶端下載的信息多於應用程序中實際需要的信息時，就會發生過度獲取，而獲取不足意味著特定端點沒有提供足夠的信息，因此需要客戶端發出額外的請求來獲取所需的信息。

從技術上講，GraphQL 是一個可以定義的包裝器，這意味著您不必完全替換 REST 系統。 從本質上講，這意味著 GraphQL 與以 REST 為中心的 API 兼容的系統兼容。 此外，GraphQL 允許前端和後端的無縫和獨立開發。 這是因為一旦架構被明確定義，前端和後端的團隊都知道數據的明確結構。 許多全棧工程師認為所有這些好處都是有利的。 最後，GraphQL 具有驚人的徹底自省和自我記錄的能力。

API 開發中的 GraphQL 用例

GraphQL 被認為非常強大，被尋求穩定可讀性、快速速度和索引的全棧開發人員使用。 具體來說，GraphQL 在需要高數據吞吐量的 API 開發中很有用。 事實上，它最大限度地減少了通過網絡傳輸所需的數據量。 這對移動用戶、低功率設備和邋遢的網絡非常有利。 這也是 Facebook 設計 GraphQL 的最初原因之一。 與想像相反，GraphQL 不僅適用於龐大的複雜數據庫，它還可以創建相對簡單的數據庫，效率更高。

此外，它可以應用在各種獨特的前端框架和平台上，提供一個使用一個 API 維護的異構環境，以滿足所有用戶的需求。 此外，它有助於快速特性開發，因為它顯著提高了全棧開發團隊的特性速度。 它通過減少團隊之間所需的通信來實現這一點，同時開發新功能，因為前端開發人員可以發出 API 請求，例如，引入新功能或更改現有功能，而無需等待後端開發人員交付。 當我們開始介紹 Hasura GraphQL 引擎時，這個快速的 GraphQL 總結應該足夠了。 雖然讓我們接觸 PostgreSQL 以獲得更多的上下文。

什麼是 PostgreSQL？

作為一個免費的社區驅動的關係數據庫管理系統，PostgreSQL 不屬於任何一家公司。 Postgres 被認為是可用的最強大、內部一致的 RDBMS，它是用 C 編寫的，並支持多種編程語言，例如 C/C++、JavaScript、Java、Python、R、Go、Lisp、.Net 等。在大多數人中越來越受歡迎全棧開發人員，PostgreSQL 比它的姊妹 MySQL 功能更豐富，因其特性、可擴展性和性能而受到歡迎。 PostgreSQL 在要求圍繞複雜過程、複雜設計、定制集成和數據完整性的項目中很受歡迎。

Postgres 對全棧開發人員的優勢

一般來說，全文搜索、JSON 列、邏輯複製等特性使 Postgres 在 MySQL 上佔上風。 這對於典型商業數據庫的性能需求是最佳的，同時允許將多個數據庫系統合併為一個以減少開銷和成本。 此外，它的鍵值存儲（JSON / JSONB 列類型）的最新功能使其成為 NoSQL 數據庫的合適替代品。 此外，它支持集群或主從架構，使其非常適合類似雲的環境。 此外，它流行的 foreign-data-wrapper 擴展允許在必要時直接從 PostgreSQL 內部查詢外部源。 具體來說，它最適合需要執行複雜查詢、數據倉庫和動態數據分析的系統。

事實上，PostgreSQL 更好地支持 MySQL 不支持的某些特性。 例如，檢查約束、豐富的數據類型（如數組、地圖、JSON）、更豐富的地理空間支持（PostGIS）和更豐富的全文支持。 此外，它還支持非阻塞索引創建、部分索引、公用表表達式和更多動態分析功能。 儘管如此，PostgreSQL 為客戶端/服務器通信加密的連接提供原生 SLL 支持，以及名為 SE-PostgreSQL 的內置增強功能，它提供基於 SELinux 策略的額外訪問控制。

PostgreSQL 具有許多企業級產品的豐富功能，適用於數據需要身份驗證且讀/寫速度對項目成功至關重要的大型系統。 此外，它還支持專有解決方案中通常可用的多種性能增強器。 其中包括：沒有讀鎖的並發性、SQL 服務器和地理空間數據支持等等。

Postgres 架構的另一個主要優勢是其獨特的可擴展性。 它允許用戶在不更改核心系統代碼的情況下添加數據類型、索引訪問方法、服務器編程語言、外部數據包裝器 (FDW) 和可加載擴展等功能。 它利用現代多核處理器架構，因此隨著內核數量的增加，其性能幾乎呈線性增長。 這很重要，一般來說，全文搜索、JSON 列、邏輯複製等特性讓 Postgres 在 MySQL 上佔據上風。 這對於典型商業數據庫的性能需求是最佳的，同時允許將多個數據庫系統合併為一個以減少開銷和成本。 此外，它的鍵值存儲（JSON / JSONB 列類型）的最新功能使其成為 NoSQL 數據庫的合適替代品。 此外，它支持集群或主從架構，使其非常適合類似雲的環境。 此外，它流行的 foreign-data-wrapper 擴展允許在必要時直接從 PostgreSQL 內部查詢外部源。 具體來說，它最適合需要執行複雜查詢、數據倉庫和動態數據分析的系統。

PostgreSQL 的缺點

一般來說，如果您喜歡 ANSI SQL 標準，請考慮使用 PostgreSQL，但如果您更喜歡 ODBC 標準，則選擇 MySQL。 不幸的是，Postgres 偶爾會在實時、“永遠在線”的生產環境中表現不佳。 Postgres 的另一個缺點是它的複制是在存儲引擎級別實現的。 這使得它比 MySQL 的複制更昂貴，後者更成熟並在“查詢引擎級別”實現。

Hasura GraphQL 引擎介紹

由於我們已經簡要介紹了 GraphQL API 開發和 PostgreSQL，我們應該有足夠的上下文來介紹 Hasura GraphQL 引擎。 基本上，Hasura 只是 PostgreSQL RDBMS 的 GraphQL 引擎，提供了一種簡化的引導和管理 GraphQL API 開發的方法。 回想起來，Hasura 是目前唯一可以立即將 GraphQL 即服務添加到現有基於 PostgreSQL 的應用程序的現成解決方案。 本質上，繞過了編寫處理 GraphQL 的後端代碼的耗時任務。

哈蘇拉簡體

讓我們花一點時間進一步簡化 Hasura。 基本上，API 是允許您請求信息（查詢）並因此通過發送 JSON 或 XML 數據進行響應的接口。 該數據庫通常託管並從服務器獲取。 這就是 Hasura 進來簡化事情的地方。 事後看來，Hasura GraphQL 引擎是一個通過 Postgres 數據庫處理 GraphQL 查詢的服務器。 這有效地減少了您的應用程序投入生產所需的時間，讓您只需單擊幾下即可輕鬆創建、查看和修改數據庫表。 因此，這允許全棧開發人員在更短的時間內在 PostgreSQL 上構建可擴展的 GraphQL 應用程序。 這為開發人員節省了數週的前期編碼時間，並且可以防止有問題的數據洩漏錯誤進入生產環境。

Hasura 在 API 開發中解決了什麼問題？

通常，Hasura 簡化了大規模生產使用期間的 API 生命週期管理，尤其是對於復雜的 API。 最重要的是，GraphQL 引擎吸引了利用現有 PostgreSQL 數據庫進行企業 API 開發項目積壓的全棧開發人員。 理想情況下，由於 GraphQL 允許閃電般快速的 API 開發週期，Hasura 為組織提供了一種簡化的方式來逐步遷移到 GraphQL，而不會影響現有的應用程序、數據庫或用戶。 除了輕量級和高性能之外，該引擎還帶有一個管理 UI，允許您探索您的 GraphQL API 並直觀地管理您的數據庫模式和數據。

哈蘇拉的優勢

首先，Hasura 有一個可靠、穩定的模型來管理數據庫更改或“遷移”。 這是有利的，因為數據庫模式管理通常很棘手。 例如，諸如以下任務； 跟踪隨時間的變化並將模式更改與 API 增強（模式管理）相關聯。 此外，諸如維護可以部署新數據庫或回滾更改的腳本之類的日常工作可能會被證明是乏味的，並且會導致難以診斷的錯誤或中斷。 作為一個積極的方面，Hasura 數據庫遷移組件是純 SQL，因此可移植到 Hasura 工具集之外。 總而言之，Hasura 具有出色的模式管理功能，您無需編寫代碼來處理 Web 套接字連接。

其次，Hasura GraphQL 引擎可以通過單個查詢輕鬆獲取所需數據。 它允許您將視圖添加為與表或其他視圖的關係。 此外，它還允許編寫具有模式拼接的自定義​​解析器，以及在數據庫事件上觸發的無服務器功能或微服務 API 的集成。 這可以派上用場，並有助於構建 3factor 應用程序。 事實上，Hasura 是一款極其輕量級的引擎。 回想起來，即使每秒處理超過 1000 個請求，它也只消耗高達 50MB 的 RAM。 可觀的投資回報！

具體來說，Hasura 進一步促進了細粒度的 API 數據級授權和身份驗證。 它允許通過 webhook、JWT、Auth0 或自定義實現連接到首選身份驗證提供程序。 因此，用戶的角色規範，定義誰可以訪問不同的數據，例如，管理員，匿名用戶等。通常，它的粒度訪問控制系統是基於類似於 GraphQL 模式的數據庫表結構。 此外，自定義權限規則是根據數據庫操作和值嚴格定義的。

最後，Hasura 出色地支持使用簡單的類似 SQL 的偏移/限制模型的高效分頁。 例如，它使用訪問控制模型來限制給定查詢返回的行數。 它的模型允許按角色調整限制。 例如，施加更高請求率的用戶被限制為更小的行限制。 這樣可以避免給數據庫和 GraphQL 引擎帶來壓力。 此外，值得注意的是，Hasura 不僅限於使用 GraphQL。 您仍然可以針對 Hasura 管理的 Postgres 表運行 REST 或其他非 GraphQL 微服務。 這可以通過 Hasura 的自動模式拼接來實現。 這允許將非 Hasura GraphQL 服務和後端合併為一個統一的模式，將新的 Hasura 管理的 API 與舊的 API 和數據相結合。

哈蘇拉用例

Hasura 引擎適用於高性能環境，提供速度，同時在現有數據庫上自動執行 GraphQL-Postgres。 因此，這為已經使用 Postgres 的公司提供了一種通過將現有錶鍊接到“圖表”來遷移到 GraphQL 的壓力較小且漸進的方式。 Hasura 有效地處理模式拼接，使您可以輕鬆應用自定義業務邏輯。 借助遠程 GraphQL 模式，Hasura 可以用作自定義業務邏輯的網關，允許您以自己喜歡的語言寫入 GraphQL 服務器，然後將數據公開給單個端點。 此外，Hasura 具有出色的查詢和突變語法，內置實時查詢，稱為 GraphQL 中的訂閱。

幾個 Hasura 限制

不幸的是，Hasura 的訪問控制系統模型不能完全適用於每個應用程序。 例如，它不完全支持單個輸入參數級別的 API 訪問授權。 更不用說它僅限於在大多數情況下需要遷移的 Postgres 數據庫。 儘管可以忽略不計，但 GraphQL API 針對格式錯誤的請求返回的錯誤消息在 Hasura 上非常不友好。 否則，正如我們在 Hasura GraphQL 引擎介紹中所見，Hasura 幾乎沒有什麼不能做的。

結論

總之，隨著 GraphQL 的發展，它將進一步簡化企業內部的 API 開發，以在 Web 規模上構建。 隨著 GraphQL 在各行各業中的廣泛快速採用，Hasura 有可能通過選擇的行業標準技術 GraphQL 和 Postgres 進一步自動化 API 的創建和管理。 Hasura簡化了 CRUD（創建、讀取、更新和刪除）GraphQL 後端的創建。 更重要的是，如果您從頭開始使用以 GraphQL 為中心的 API 和 Postgres，而無需編寫後端代碼，Hasura 是迄今為止最好的也是唯一的選擇。 有關 GraphQL 和 Hasura 企業可能性的任何疑問或諮詢，請隨時與我們聯繫。 這就是我們對 Hasura GraphQL 引擎的介紹。