?譯者 | 布加迪

審校 | 孫淑娟

GraphQL正迅速成為許多公司處理數(shù)據(jù)的首選查詢語言。雖然數(shù)據(jù)管理是許多公司最關心的問題之一，但許多人并不真正了解GraphQL的作用或為何如此大受歡迎。

全世界每天平均生成約2.5萬億字節(jié)的數(shù)據(jù)。企業(yè)需要一種方法來收集這些數(shù)據(jù)并有效地使用數(shù)據(jù)。大量數(shù)據(jù)在應用程序中生成（比如客戶服務智能手機應用程序讓客戶可以告訴您他們是否滿意，或者他們是否有任何問題、需要幫助排除問題）。應用程序需要一種將信息發(fā)送到后端的方法，即管理和存儲數(shù)據(jù)的工具。然后可以分析數(shù)據(jù)，發(fā)現(xiàn)問題、制定解決方案。當然這是雙向的。應用程序不僅將數(shù)據(jù)發(fā)送到后端，應用程序也需要來自后端的數(shù)據(jù)，比如推薦、交貨狀態(tài)、賬戶余額。這正是GraphQL擅長的：將數(shù)據(jù)發(fā)送到后端，并從后端獲取數(shù)據(jù)。它是一種更現(xiàn)代的API，可將應用程序連接到后端。

雖然許多技術領導者可能聽說過GraphQL，但對SQL（結(jié)構(gòu)化查詢語言）可能更熟悉。SQL本質(zhì)上是數(shù)據(jù)庫查詢方面的行業(yè)標準，不過GraphQL的風頭越來越勁。

GraphQL與SQL相比如何？有沒有辦法在執(zhí)行查詢時做到兩者的好處兼而得之？

1.GraphQL vs SQL：全面比較

GraphQL有比較簡單、易讀的數(shù)據(jù)訪問格式。這種獨特的格式允許所謂的“嵌套”（nesting）。嵌套好比在一個問題中提出另一個問題，以獲得更具體的答案。比如說，您可能索要列出所有狗的列表以及這些狗各品種的嵌套詳細信息（從完全不同的數(shù)據(jù)源、甚至第三方數(shù)據(jù)源獲?。皇莾H僅索要列出某個棲息處的所有狗的列表。

QraphQL嵌套查詢的能力讓前端開發(fā)人員可以通過一個請求從API獲取相關信息。由于GraphQL幾乎是一種通用查詢語言，可以輕松處理不同的數(shù)據(jù)源，您還能同時查詢多個API及其他數(shù)據(jù)源。因此GraphQL是適合異構(gòu)后端的查詢語言，這意味著除了數(shù)據(jù)庫外，后端還有不同類型的數(shù)據(jù)源。

作為一種數(shù)據(jù)庫查詢語言，SQL非常流行。遺憾的是，它并不像 GraphQL 那樣適用于跨異構(gòu)數(shù)據(jù)的嵌套查詢。另外，SQL的語法可能很復雜。最后，SQL從未打算普遍通用。SQL適用于不同的數(shù)據(jù)庫，但不適用于API。

2.GraphQL與SQL的實際異同?

假設您在為公司的庫存補貨，需要知道從兩家不同公司發(fā)貨的兩筆不同訂單的跟蹤編號和預計交貨日期。GraphQL就能夠通過一個請求獲取所有這些信息。

GraphQL還以分層結(jié)構(gòu)向您顯示該信息，分層結(jié)構(gòu)使您可以輕松查看請求的數(shù)據(jù)之間的關系。換句話說，您可以看到包裹的交付日期與收到的跟蹤編號相關聯(lián)。

如果是SQL，您可能需要向數(shù)據(jù)庫發(fā)出一個請求，以獲取有關兩筆不同訂單的一般信息。然后，您可能需要對該信息進行分類以查找發(fā)貨公司的名稱，然后向每家發(fā)貨公司發(fā)出另一個請求，索要跟蹤編號。最后，根據(jù)跟蹤編號，您可能發(fā)出另一個請求，以獲取預期的交貨日期。獲取所有這些信息需要大量代碼，僅僅確保語法正確可能并非易事。幾十年來，本人一直與SQL數(shù)據(jù)庫打交道，連我都常常需要查詢復雜查詢的語法。

3.為什么SQL仍然如此流行？

GraphQL API模式僅允許一小部分操作，具體取決于實現(xiàn)該API的開發(fā)人員。換句話說，查詢的靈活性取決于API開發(fā)人員的靈活性。比如說，API只允許您通過電子郵件搜索客戶。要按城市搜索客戶，應用程序就需要收集所有客戶，然后一一過濾。

或者如果您在處理敏感數(shù)據(jù)，可能需要針對多個因素來配置查詢和API：比如控制誰可以訪問數(shù)據(jù)，或數(shù)據(jù)在后端緩存（臨時保存）多久。這樣的配置對于普通公司來說要求過高，但現(xiàn)在有許多技術可以為您管理和配置GraphQL查詢和API。這些技術使GraphQL成為了查詢API的可行選項，但如果沒有這些技術，配置可能很困難。

相比之下，SQL一開始更具表達力，這意味著它可以更輕松地告訴系統(tǒng)您想要什么，無需進行大量的額外配置。只需使用一行代碼，您可以輕松地查詢?nèi)魏螖?shù)據(jù)庫：“針對客戶 John Doe，請給我金額超過100美元的訂單”。無論數(shù)據(jù)庫結(jié)構(gòu)如何，SQL都會為您提供所需的數(shù)據(jù)。

GraphQL允許在構(gòu)建API的開發(fā)人員設置的框架內(nèi)進行靈活查詢，而SQL允許對任何數(shù)據(jù)庫模型進行通用查詢。因此，如果您以查詢數(shù)據(jù)庫為主，SQL可以很好地完成工作。

4.有沒有辦法彌合鴻溝？?

如果可以同時利用SQL的表達性和GraphQL 的靈活性，那將會怎樣？市面上有一些技術聲稱可以做到這一點，但它們不太可能變得流行起來，因為它們最終很笨拙很復雜。笨拙源于試圖將SQL構(gòu)件（construct）強行塞入到GraphQL中。但它們是兩種不同的查詢語言，用途不同。如果開發(fā)人員必須學習如何在GraphQL中做SQL構(gòu)件，還不如使用SQL并直接連接到數(shù)據(jù)庫。

然而，還有一線生機。我們認為，GraphQL會逐漸變得更具表達力。有一些方案旨在讓GraphQL更具表達力，這些方案最終可能會成為標準。但從根本上說，SQL和GraphQL各自看待世界的視角不一樣：統(tǒng)一的后端vs多樣化的后端，表vs.分層數(shù)據(jù)，通用查詢vs.有限查詢。因此，它們用途各異。

盡管GraphQL 作為一種API查詢語言很受歡迎，但它不會取代SQL這種數(shù)據(jù)庫訪問的主要語言。

原文鏈接：https://venturebeat.com/2022/08/04/graphql-is-a-big-deal-why-isnt-it-the-industry-standard-for-database-querying/?