GraphQL 將為去中心化網路提供動力

買賣虛擬貨幣
利用區塊鏈和儲存網路作為資料互操作性層編者按: 在 ArcBlock 的產品設計中,基於 GraphQL 的 RPC 是無處不在的,我們的開發鏈訪問協議(OCAP)的查詢語言就使用了 GraphQL,我們的 ArcBlock 區塊鏈開發框架的 RPC 服務介面也是採用了 GraphQL。為什麼我們在設計上更青睞 GraphQL,而不是更常見的 REST ful 的 API,或者 JSON RPC 呢?剛好讀到 Brandon Ramirez 這篇文章分享了他的看法,與我們心有慼慼焉,特此翻譯推薦給大家。作者: Brandon Ramirez譯者: 陳俊數十年來,市面上唯一被廣泛使用的資料庫是 SQL 資料庫,它仍然是大多陣列織,軟體應用和機構的核心。然而,隨著區塊鏈的到來,關聯式資料庫終於有了替代選項,而且我談論的不只是 NoSQL 運動帶來的增量改進。我們正處於所謂去中心化網路或 Web3 等新範例的風口浪尖,其中資料(而非專有 API)是互操作性的基礎。在這篇文章,我將解釋為什麼會發生這種轉變,以及 GraphQL 查詢語言如何被獨特地定位以支援這個新的資料互操作時代。專有 API 的問題
當今的全球資訊網是透過專有的應用程式設計介面(API)相互連線起來,API 的存在主要是為了解決中心化(通常為 SQL)資料庫的侷限性。在描述事態時,以前在以太坊基金會工作的 Vinay Gupta 觀察到:“當你在組織的核心擁有一個大型資料庫時,該資料庫可以儲存所有真相和所有真知,你非常不願意讓其他人接觸該資料庫。”因此,在伺服器上執行的專有 API 會成為中心化資料庫的保護屏障。它們限制了輸入、輸出、由誰,以及以什麼格式。使用微服務模式,我們甚至可以將資料封裝在組織內部,這樣由不同團隊構建的服務必須透過彼此的 API。雖然這使我們到達了今天的位置,但 API 的這種氾濫具有以下缺點:1.API 僵化且維護成本高;2.當前模型效率低下;3.專有 API 導致資料壟斷。且讓我們一一詳解:
1. API 僵化且維護成本高API,特別是 REST API,在設計時考慮了特定的用例,例如 Web 應用中的功能,並且你從這些用例中獲得的資訊越多,使用起來就越困難。在組織內部,這導致 API 表面積不斷擴大。每個新功能都需要進行額外的工程設計工作才能用新的端點來擴充套件 API。反過來,每個新端點都需要正在進行的工程工作來維護和支援其使用期限,這可能要花很長的時間。同時,對於公開 API 的使用者而言,他們受制於 API 開發者決定支援的用例。Github 的生態工程總監 Kyle Daigle 明確指出了這個問題:“幾乎每個 API 都透過其設計來驅動整合……我能想到的每個 API……它們都對如何使用它們有一定的主意,如果你想顛覆它,那基本上是不可能的……你必須去抓取大量資料庫,將其貼上在資料庫中,並以此為基礎構建自己的 API。”這些公開 API 的剛性需要大量額外的工程工作來解決,這就引發了下一個問題。2. 當前模型效率低下
如我們所見,API 的剛性導致大量資料庫和 API 激增,它們通常以不同的格式或在不同的 API 語義之後儲存完全相同的資料。這些新資料庫和 API 均需要其他基礎結構和工程資源來維護。這也導致大量的迂迴曲折。再次引用 Vinay Gupta 的話:“當你向國稅局提交表單時,它需要經過 6 或 7 個流程才能在其資料庫中顯示出來……整個協作是間接的、官僚的、困難的。”在研究這一資料問題的論文中,Brendan O’Brien 和 Michael Hucka 將 SQL 資料庫的首要地位描述為“中間資料庫”模式,如下所示:

任何足夠簡單的軟體系統都將涉及無數伺服器,這些伺服器對來自一個資料庫的資料進行編碼,透過網路提供資料,對資料進行解碼,將其放入另一個資料庫中,並重復多次此過程。

O’Brien 和 Hucka 描述了一種常見現象:要麼在這些資料管道中如何將中間結果儲存在私有資料庫中,要麼由於要讓這些資料可公開使用而需要進行的工程工作而被完全淘汰。結果是重複勞動的兩個維度:在資料管道內,以及由孤立的團隊和組織建立的各種資料管道之間。

3. 專有 API 導致資料壟斷

將資料放入孤島的必要性也導致道德風險。它已成為技術領域的一種常見情形,一家主要的技術巨頭之前鼓勵開發者在其平臺上進行開發之後,撤消了對其專有 API 的訪問。

Facebook 故意這樣做是為了扼殺競爭,而 Twitter 則是為了更有效地利用其資料獲利。InfoWorld 資深作家 Serdar Yegulalp 談到了 Twitter 的故事,扼要敘述了開發專有 API 的風險:”稱它為 API 經濟的職業危害之一:對單個實體的依賴越廣泛和多面化(無論是作為資料來源,分析層還是基礎架構),從地毯中抽出地毯越容易在你的腳下。“

要求資料置於閘道器之後的軟體架構範例自然會引發這些資料壟斷的有害實踐。

為了避免失之偏頗,我應該指出基於 API 的連線已經取得了巨大的成功。透過讓開發者能夠用諸如 Stripe 或 Twilio 之類的小型專用服務編寫軟體,API 創造了不可估量的經濟價值。他們為我們提供了一種在 SQL 主導的傳統技術領域中的應用之間安全傳輸資料的方法。沒有 API,我們今天所知道和喜愛的網際網路將無法實現。但是現在,隨著區塊鏈和其他 Web3 技術的出現,我們有機會進入網際網路無摩擦、互操作性的新時代。

進入區塊鏈和內容定址儲存

SQL 和大多數 NoSQL 資料庫的主要缺點是它接受對資料進行適當修改的資訊模型。Clojure 程式語言和 Datomic 資料庫的建立者 Rich Hickey 稱之為“面向位置的程式設計(PLOP)”,儘管有必要克服小記憶體和磁碟尺寸的侷限性,但它在現代的資訊模型已不再佔有一席之地。如果可以透過任意方式就地更改資料,那麼就無法相信資料是正確的,或者自從上次訪問以來沒有發生任何更改。因此,去中心化網路的兩種賦能技術:區塊鏈和基於內容的儲存,都在其資訊模型中強調不變性也就不足為奇了。

內容定址儲存

儘管區塊鏈的熱度要大得多,但我將首先介紹內容定址儲存,因為它是更簡單更基礎的概念。這個想法是:對於任何資料片段(資料庫中的實體、檔案系統中的檔案、CDN 上的 Blob),你如何引用這些資料?是否給它提供一個任意的 ID、URL 或名稱,根據你的詢問方式,它可以在不同的時間引用不同的資料……還是給它一個唯一的 ID,該 ID 可以永遠永久地解析為特定值,無論它是從在你自己的本地檔案系統,在遠端伺服器上,還是從另一個星球提供?

內容定址儲存網路,例如星際檔案系統(IPFS)或分散式版本控制系統(Git),採用後一種方法,即使用從內容本身唯一來計算(使用雜湊函式)ID。因為內容 ID 應該始終返回相同的內容,而後者又可以用來重新計算 ID,所以驗證資料的完整性是微不足道的。

在這一點上,你可能會問自己,如果內容定址儲存是不可變的,那麼我們該如何做些有用的事情呢?畢竟,在現實世界中,我們使用資料來表示的事物,例如你的銀行帳戶餘額、你的朋友列表、你的待辦事項列表,會隨時間變化。我們如何使用不可變資料作為核心構建模組來表示隨時間變化的概念?這就是區塊鏈發揮作用的地方。

區塊鏈

區塊鏈的核心是不可變值的僅附加資料結構:一系列區塊組成的鏈。儘管每個區塊都是不可變的,但我們可以透過使變數(例如帳戶餘額或智慧合約狀態)的價值因區塊而異來模擬可變性。透過這種模式,我們可以自由獲得可審計性,這意味著我們可以看到任何變數隨時間變化的情況,從而允許外部流程放心地直接依賴於此資料。

具有智慧合約功能的區塊鏈(例如以太坊),也為我們提供了一種方法,以編碼方式修改資料片段以及用安全的方式由誰來修改資料——這通常是由中心化 API 的職責。

這兩項創新開啟了一個新的範例,其中儲存在區塊鏈和內容定址網路的資料充當了互操作性層:

由於區塊鏈被設計為去中心化、使用者無需許可即可參與,且可在存在某種惡意的環境中執行,因此無需為了保護安全性和健壯性而將它們隱藏在某些額外的保護層之後。對於存在區塊鏈或內容定址儲存網路中的資料,專有的 API 不再是架構的必需——流程可以與去中心化資料直接互動,作為實現互操作性的共享基礎。

查詢去中心化資料

如果區塊鏈是一種新型的資料庫原語,那麼我們將如何查詢該資料?是透過 RESTful API、RPC 呼叫,SQL 介面嗎?答案將不可避免地是上述所有,但對於旨在提供在區塊鏈之上開發構建的消費者級效能的去中心化應用,GraphQL 是自然的選擇。

GraphQL 比 REST 或 RPC API 更有效

GraphQL 既是查詢語言又是介面定義語言(IDL),是由 Facebook 發明和開源的。它旨在克服傳統 RESTful API 的僵化和效率低下的問題,我們在之前已對此進行了討論。它透過直接向 API 使用者展示功能強大但符合人機工程學的查詢語言來實現此目的。

使用傳統的 REST(表示狀態傳輸)API,每個實體或資源都有一個單獨的端點,該端點定義了你將收到的有關該實體的資料。例如,要獲取使用者所屬組織的名稱,你可能必須首先呼叫:

/api/v2/users/1

然後呼叫:

/api/v2/organizations/7

基於傳統 API 構建的現實應用可能會進行數十或數百次往返網路呼叫。而且,這不僅僅是 REST 的問題。例如 AdChain 是一個流行的去中心化應用,它建立在以太坊 RPC API 的基礎上,並被迫向 Infura 進行數百次往返網路呼叫以載入其 UI,從而導致網路擁塞和載入時間不理想。

截至撰寫本文時,AdChain 登錄檔對 Infura 進行了數百次網路呼叫:https://publisher.adchain.com/domains

另一方面,GraphQL 功能強大,足以在單個查詢中表達應用所需的所有資料。無論你需要多少資料,使用 GraphQL 都不需要進行多個網路呼叫。有時這稱為解決獲取不足問題。此外,你只需要獲得所需的確切資料,而不需要獲得更多資料,從而解決了過度提取的問題。

結果就是介面的使用方式就少了很多,它們只為你提供所需的資料,不需要不斷更新以支援外部開發者的新用例。

對於去中心化應用,GraphQL 比 SQL 更好


但是為什麼不使用某些查詢語言(如 SQL)來查詢資料區塊鏈呢?

明確地說,我認為這可能並且應該發生。SQL 已在全球範圍內廣泛採用,為數百萬的開發者所熟悉,並且比 GraphQL 作為查詢語言更強大。資料科學家和資料工程師尤其熟悉,他們可能不熟悉 GraphQL。話雖如此,SQL 不會成為構建在區塊鏈上的去中心化應用(dApps)首選的語言。

基於區塊鏈構建的 dApp,GraphQL 會勝過 SQL 的幾個主要原因:

1.GraphQL“足夠強大”
2.GraphQL 對於前端開發者更符合人機工程學
3.GraphQL 旨在跨組織信任邊界使用

讓我們一一介紹。

1. GraphQL“足夠強大”

即使 GraphQL 查詢語言本身不像 SQL 那樣具有豐富的表達能力,但經過精心設計的 GraphQL 端點可以為你提供你期望從 SQL 查詢介面獲得的大多數查詢功能。例如,GraphQL 規範本身並未指定進行聚合的方式,但是出現了諸如 OpenCRUD 之類的標準,用於指定如何公開此功能。

仍然存在一些長尾功能,例如跨實體的臨時連線,對於 GraphQL API 而言可能永遠無法實現。但是,我估計對於前端應用所需的 99.9%用例,GraphQL 足夠好。

2. GraphQL 對於前端開發者更符合人機工程學

透過選擇 GraphQL,你只需付出一點點就可以適應人機工程學。例如,GraphQL 具有類似 JSON 的語法:

query {
user(id:1) {
name
organization {
name
 }
}
}

而且,GraphQL 查詢的響應是一個 JSON 物件,它完全反映了請求的形狀。

{
"user": {
"name": "Vitalik",
"organization": {
"name": "Ethereum Foundation"
}
}

鑑於 JSON 是用於在 Web 上傳輸資料的最常用資料格式,因此對於大多數 Web 開發者而言,這種語法是難以置信的易用。

同時,等效的 SQL 查詢如下所示:

SELECT user.name, organization.name
FROM user JOIN organization ON (user.organization_id=organization.id)
WHERE user.id=1

這並不是最糟糕的事情,但是可以說它不如 GraphQL 查詢那麼直觀簡單。

而且,響應資料將被反規範化並以表格形式傳送,並以你碰巧使用的特定 SQL 資料庫的專有有線協議傳送。這與 GraphQL 響應的直觀巢狀相反,後者透過 HTTP 傳送的純文字 JSON 表示。

GraphQL 生態還具有諸如 React-Apollo 之類的工具,讓透過 GraphQL 提取的資料直接整合到 Web 應用的 UI 元件中變得異常簡單。由於幾乎從未直接從移動或 Web 應用透過 HTTP 使用 SQL,因此我所知道的 SQL 生態系統中不存在這樣的工具。

3. GraphQL 旨在跨信任邊界使用

也許更重要的是,SQL 端點從未設計為跨組織信任邊界使用的端點。例如,如果我們使用 SQL 提供只讀的區塊鏈資料,那麼過於複雜的 SQL 查詢足以使你的資料庫進入抓取狀態,從而使其他任何人都無法使用它。

GraphQL 的功能同樣足夠強大,可以在後端觸發任意昂貴的計算,但是與 SQL 不同的是,解決該問題從一開始就成為重點關注的領域,並且越來越多的研究和工具能夠動態阻止昂貴的查詢和客戶端節流。

同時,解決 SQL 中此問題的類似方法傳統上是手動查詢慢查詢並簡單地重寫它們。或者可以新增索引或更改資料庫架構,以減輕“批准的”昂貴查詢的影響。這就是 SQL 始終在組織中部署的本質,只有嚴格控制的人員或服務才能直接查詢端點。

GraphQL 的跨組織基因閃耀的另一個地方是其模式自省。GraphQL 將模式自省視為該語言的頭等大事。

例如,GraphQL 中的 Root 型別具有 _schema 欄位,可用於自省可查詢的型別:

// GraphQL request
query {
**schema {
types {
name
description
fields {
name
}
}
}
}
// JSON response
{
"data": {
"**schema": {
"types": [
{
"name": "Root",
"description": null
},
{
"name": "User",
"description": "A user of the platform."
"fields": [
{ "name": "name" },
{ "name": "id" }
]
},
{
"name": "Organization",
"description": "An organization of the platform."
"fields": [
{ "name": "name" },
{ "name": "id" }
]
}
 ]
}
}
}

為了對 SQL 公平起見,儘管一些自省查詢看起來確實很恐怖,但是如果你熟悉以下語法,則上述內容的大部分自省看起來並不可怕:

SELECT c.table_schema,c.table_name,c.column_name,pgd.description
FROM pg_catalog.pg_description pgd
RIGHT JOIN information_schema.columns c on
(pgd.objsubid=c.ordinal_position)
WHERE c.table_schema NOT IN ('pg_catalog', 'information_schema');

然而,這一 SQL 查詢充滿了 Postgres 資料庫的供應商特定的引數。MySQL 資料庫的等效查詢將有所不同。另外,儘管上述查詢很容易以純文字形式閱讀,但傳送查詢和接收響應卻需要特殊的工具:特定供應商的 CLI 客戶端或跨供應商的桌面 GUI,可以理解特定供應商的 SQL 風格,有線協議,ODBC 或以上各項的組合。

另一方面,GraphQL 會針對所有查詢(包括自省查詢)透過 HTTP 返回純文字 JSON,以便你可以使用 Postman、Chrome 開發工具或預裝在每臺 Mac 和 Linux 作業系統終端上的簡單 curl 命令踢除端點上的煩惱。

結論

確實,我所強調的 REST 和 SQL 的許多缺點並非沒有補救措施。人們一直在努力解決 RESTful API 的獲取過度和不足的問題。一直存在將架構新增到 RESTful API 中的努力,理論上可以從預定義的端點提供服務。SQL 還是一種查詢語言,而不是一種實現,因此,沒有什麼可以阻止我們構建使用 HTTP,透過網路返回純文字 CSV 或 JSON 並具有更明智的自省功能的 SQL 介面。但是,像現在啟用區塊鏈和基於內容定址的儲存網路一樣,跨組織信任邊界直接有效地查詢任意資料根本不存在這兩種技術中的任何一種的基因之中。

同時,GraphQL 是針對該用例進行全新設計的。它的設計考慮了對前端工程師使用者友好的圖形介面,和能夠幾乎無縫地將 GraphQL 查詢宣告性繫結到瀏覽器中的 UI 元件的成熟工具。在 dApp 主要由與執行在區塊鏈上的智慧合約介面的瀏覽器應用組成的範例中,前端工程師的需求和偏好將成為確定去中心化 Web 技術堆疊的動力。這就是為什麼我們已經看到了為什麼有很多努力將 GraphQL 介面放在以太坊的 JSON RPC API。

在 Graph,我們認為在區塊鏈之上建立具有消費者級效能的豐富使用者體驗是實現區塊鏈和去中心化網路廣泛普及的主要障礙之一。因此,去年 7 月我們開放了索引伺服器的原始碼,讓開發者可以透過 GraphQL 介面有效地查詢以太坊和 IPFS 資料,以瞭解其去中心化應用。將來,隨著資料科學和區塊鏈上機器學習的分析管道成為更常見的用例,我們將著眼於支援 SQL 以及其他查詢語言……Datalog,有人用嗎?

來源: Medium 文章 GraphQL Will Power the Decentralized Web[1]

References
[1] GraphQL Will Power the Decentralized Web: https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;