SQL是比GraphQL更好的API語言?

banq發表於2020-04-17
SQLAPI

Datasette是一個使用SQL實現API查詢的專案，Datasette的建立者和Django的共同建立者Simon Willison認為：SQL是比GraphQL更好的API語言。

眾說紛紜：
Datasette的口號是“一種用於探索和釋出資料的工具”，對我來說，SQL（具有適當的限制）是對資料集執行的各種操作而言是一種合適的API，這在很大程度上是有意義的。這實際上不是典型的Web API用例，通常情況下您會遇到更多專門化和受限的使用場景。

作為Datasette專案的一部分，我已經使用SQL作為API查詢語言已有兩年，我開始認為用於API查詢的SQL確實是一個糟糕的主意。Datasette之所以支援它，是因為它被設計為即席查詢工具（恰好能夠將結果匯出為JSON），但是對於生產應用程式來說，這顯然是個糟糕的主意。

我過去曾嘗試過幾次。我認為我遇到過的最大問題是資料庫修改。在這些情況下，我不僅需要更新我的api伺服器中的查詢，還需要更新我的客戶端程式碼，而對於多個客戶端，這變得更加困難。總的來說，我認為客戶端上的SQL非常好-甚至很理想。實際上，我嘗試開發僅生成使用者特定資料庫摘錄的api，其中SQL非常適合在客戶端本地查詢資料。去年，由於這個確切的原因，我嘗試在瀏覽器中執行sqlite，但是它太繁瑣了。

我認為在這次討論中變得越來越清楚的是，有一些開發人員（肯定包括我自己）願意使用SQL作為實際資料庫之外的簡單程式設計結構的介面。

我覺得這個討論很容易使人意識到“在客戶端執行任何查詢”是一個糟糕的主意，而這正是大多數GraphQL安裝程式所提供的優點。儘管我喜歡GraphQL，但當進行安全滲透測試時，它是一個非常方便的資料滲透引擎。預設情況下，沒有授權，沒有身份驗證，甚至帶有自省功能。與SQL隱碼攻擊，不安全的S3儲存桶或錯誤配置的NoSQL例項相比，這種技術如果形成流行趨勢將對資料安全而言將更加糟糕。

雖然我也看到了許多安全性差的GraphQL API ：，但認為GraphQL安全性差似乎是一種不公平的批評。對我來說，GraphQL通常是REST的一種替代方案，後者預設情況下也沒有任何授權或身份驗證，這是一個正交的問題，但是不能怪罪REST。

GraphQL有意義的是前端進行大量複雜而複雜的呼叫的情況。如果它是一個簡單的REST api，則與其進行互動可能不需要GraphQL，並且實際上可能會對其造成損害。

對我來說，GraphQL僅適合在客戶端進行快速原型製作/更改的靈活性很重視時。

實際上GraphQL是讓我重新考慮在客戶端執行查詢是否是個壞主意的事情，這是我開始認真嘗試客戶端SQL的原因之一。我絕對同意，您必須非常小心安全。根據我在足夠大的團隊中的經驗，有人會在某個時候搞砸，所以在任何客戶端查詢機制中這都是很大的風險。

就像生活中所有美好的事物一樣，這裡存在一個折衷。當您所請求的內容最好表示為樹（或“圖形”，儘管只有DAG變體）時，GraphQL更好。並非總是如此，但是在構建供生產使用的API時通常是這樣。當然，您可以用表格形式表示樹結構，但是客戶端使用它並不十分方便。特別是如果您的客戶端正在渲染巢狀的元件檢視，則您所需的通常是分層的。GraphQL對我們的生產人員來說更好的另一個方面是效能更可預測，這恰恰是因為該語言受到更多限制。您不僅可以加入所有內容，也不能偶然選擇數十億行。該模式指示允許的內容。當然，同樣可以在SQL中進行限制，只需適當地配置您的架構，限制等，但是SQL預設情況下可以執行任何操作，而GraphQL預設情況下則不允許。這就是說，作為一種語言，SQL顯然是優越的。它是最成功的4GL（說明性）語言。我希望更多的語言經過精心設計，並希望在此方向上有更多的語言創新。從我的角度來看，GraphQL是一種DSL，用於以JSON格式靈活地從API：請求分層資料，並針對複雜的不斷髮展的API進行了最佳化。SQL是用於關係資料轉換的成熟通用語言。

HN討論



 

相關文章