為什麼 Open Chain Access Protocol 採用 GraphQL

作者： Jean Chen（ArcBlock 公關副總裁）

ArcBlock 的工程團隊將定期接受訪談或撰寫工程部落格，為 Open Chain Access Protocol 背後的設計理念與實作細節進行「解密」，並拓展公眾對其的理解。我們歡迎大家提出建議，幫助我們進一步改進設計與產品。

第二篇文章「為什麼 Open Chain Access Protocol 採用 GraphQL」是 ArcBlock 行銷團隊透過一系列對工程團隊的訪談所撰寫。這一次，我們將首次深入探討 ArcBlock 採用新世代查詢語言 GraphQL 的原因。

儘管全球加密貨幣市場目前處於低迷期，但今年區塊鏈技術已進入底層公鏈項目的 3.0 時代。作為 1.0 與 2.0 時代代表的 Bitcoin 與 Ethereum，一直受到效能低、設計不友善、功能不足、成本高、平台「鎖定」等痛點困擾，但層出不窮的新公鏈則提出了各式各樣的技術解決方案。

其他公鏈正在推動區塊鏈技術的普及，回應消費者的需求，主要聚焦於去中心化應用（Dapps）的發展與成功，但 ArcBlock 的不同之處在於：它不是一條新的公鏈，而是一個應用開發平台。ArcBlock 利用雲端技術幫助開發者存取並連接各種公鏈，讓他們能專注於開發 Dapps，使區塊鏈應用的設計像網頁與行動應用程式一樣簡單。

Open Chain Access Protocol 將成為建立這類雲端運算平台的堅實基礎，相當於 J2EE 或微軟的 .net framework。這個開源協議提供一個抽象化介面層來存取底層區塊鏈，協助開發可在不同區塊鏈上運作的應用。類似於資料應用中的 ODBC 與 JDBC 關係，當 Dapps 在不同底層區塊鏈之間切換，或使用多種不同協議的區塊鏈時，甚至不需要更改你的業務邏輯程式碼。

為了幫助開發者輕鬆存取連線並切換到底層公鏈，而不是使用已被業界廣泛採用的 RESTful 作為 API 查詢語言，ArcBlock 採用了 GraphQL。

什麼是 GraphQL？

GraphQL 是新一代 API 查詢語言，Facebook 於 2012 年開始內部使用，並於 2015 年開源。在 GraphQL 的官方網站上，他們用程式碼展示了其主要特性。

API 開發者只需要描述 API 的 schema，並為其提供合適的 resolver。客戶端可以有效地使用 GraphQL 查詢格式來查詢資料，而伺服器會根據客戶端的需求回傳對應結果。

GraphQL 支援 Query（資料查詢）、Mutation（資料更新）與 Subscript（資料監聽）API。每個 API 都會透過 resolver 回傳客戶端所期望的結果，如下圖所示：

GraphQL 中的 graph 是一個有向圖，查詢的每一層都對應一個 resolver，因此資料會一層一層往下解析，取得使用者所需的所有資料：

與 RESTful 相比，GraphQL 更高效、更強大也更靈活。它允許你在客戶端定義要查詢的資料結構，並由伺服器回傳相同的結構，而不是回傳冗餘資料。

當你向 API 發送 GraphQL 查詢時，可以精準取得所需要的內容，不多不少。GraphQL 查詢總是回傳可預期的結果。使用 GraphQL 的應用程式快速且穩定，因為它們能自行控制所取得的資料，而不是由伺服器決定。

GraphQL 查詢不僅可存取某個資源的屬性，也能順暢地沿著它們之間的引用關係追蹤。典型的 RESTful API 通常需要從多個 URL 載入資料，而 GraphQL API 則能在單一請求中取得應用程式所需的所有資料。使用 GraphQL 的應用程式甚至能在緩慢的行動網路連線下快速運作。

GraphQL API 是以 types 和 fields 來組織，而不是以 endpoints。GraphQL 使用 types 來確保應用程式只會提出可行的請求，並提供清楚且有幫助的錯誤訊息。應用程式可以利用 types 避免撰寫手動解析程式碼。你可以從單一 endpoint 存取資料的全部能力。

總結來說：GraphQL 為你的 API 中的資料提供完整且易於理解的描述，並賦予客戶端以下能力

問與答

在 OCAP 上線一個多月後，ArcBlock 創辦人兼首席架構師 Robert Mao、工程副總裁 Tyr Chen，以及 OCAP 專案首席開發者 Peiling Ding，從不同角度回應了有關 OCAP 技術的問題。

為什麼我們選擇在 OCAP 中使用 GraphQL？

Robert Mao： 從開發者的角度來看，GraphQL 簡單、直觀、容易學習，也容易除錯。它的跨平台應用非常方便，適合前端開發，複雜度被隱藏並封裝在後端伺服器中，非常適合應用開發。考慮到 ArcBlock 是一個支援區塊鏈應用的平台，OCAP 需要支援多種不同的底層區塊鏈，而目前的區塊鏈並沒有統一的標準與架構，因此我們需要一種能夠描述彈性查詢與資料結構的語言。GraphQL 的設計非常適合這種情境。使用 GraphQL 有助於統一區塊鏈、傳統資料庫與網頁服務之間的連接與整合。最後，GraphQL 擁有成熟的社群與豐富且可直接使用的工具框架。

Peiling Ding： ArcBlock 之所以這樣選擇，是因為它考量了開發者的體驗，並希望讓這種體驗是愉快的。作為查詢語言的 GraphQL，會讓前端查詢更靈活且更有效率。業界最常用的做法是提供一組 RESTful API。在伺服器端，我們設置許多 endpoint，每個 endpoint 接受一些參數並提供一些服務。這樣做的表面好處是伺服器端容易實作，而且一般使用者可以很容易透過瀏覽器存取。然而，缺點是設計不友善。在 RESTful API 中，查詢的發起是以 endpoint 為基礎，這些 endpoint 的組織較為鬆散，使得客戶端的程式碼維護變得複雜，對開發者也不友善。

Tyr Chen： 從應用開發的角度來看，使用 GraphQL 會降低客戶端開發者在資料存取上的壓力。客戶端想要存取的深層資料，例如 Bitcoin 的 UTXO 查詢請求，若使用 RESTful API，會回傳你不需要的冗餘資料，因為你其實只需要查詢交易雜湊。使用 GraphQL 會顯著降低應用開發者存取資料的壓力。這就像用 SQL 查詢資料庫一樣。當 GraphQL 查詢區塊鏈資料、發起查詢行為並傳送到伺服器時，它會從不同資料來源取得資料並組裝成查詢回饋回傳，這可以最佳化網路傳輸資料。伺服器回傳客戶端所需要的任何資料。

GraphQL 如何幫助 OCAP 實現統一而直接的跨鏈操作？

Tyr Chen： GraphQL 更好地實現了 OCAP 開發鏈路存取層三個層級中的 API 定義。例如：在第一層的主鏈 API 中，在 OCAP 的第一版裡，使用 GraphQL 查詢各種資料集非常方便，例如 Ethereum 和 Bitcoin；在第二層的主鏈 API 中，GraphQL 可以區分不同區塊鏈的能力——Bitcoin 和 Ethereum 分開查詢，但它們的語法結構與使用者撰寫查詢的方式是相似的。開發者不需要太多指引，他們存取區塊鏈的能力可以很容易從一條鏈轉移到另一條鏈。ArcBlock 也建立了專屬於開發者的 OCAP Playground，透過自動完成幫助你更有效率地建立查詢，顯著降低記憶成本，並快速查詢對應結果。

Robert Mao： OCAP 使支援多種不同區塊鏈協議成為可能。應用開發者可以從多種不同的區塊鏈協議、不同節點類型與不同部署模式中，自由選擇最合適的方法。開放鏈存取層定義了統一的 API，但這些 API 的具體實作則來自 chain adapter。

為什麼目前使用 GraphQL 的區塊鏈技術產品不多？

Tyr Chen： 雖然 Facebook 已經使用了好幾年，但 GraphQL 仍然相當新。無論前端或後端，大多數開發者仍然熟悉 RESTful API。許多技術供應商也更偏好透過 RESTful 提供服務。然而，我相信會有越來越多人使用 GraphQL。此外，GraphQL 在伺服器端也有許多門檻。

Peiling Ding： 如果你要開發一個可存取、以瀏覽器為基礎、可串聯的資料存取服務，你會傾向使用傳統的 RESTful API，因為你不能要求大家去學習 GraphQL。ArcBlock 在服務對象方面與其他公司不同。不過，最終大家還是會打開瀏覽器，輸入 URL 來上線。

ArcBlock 如何善用 GraphQL 現有資源並為 GraphQL 社群做出貢獻？

Robert Mao： 雖然 Facebook 已經將 GraphQL 開源，但它只揭露了框架語言，並沒有提供具體的實作方法。因此，在使用 GraphQL 開發 OCAP 的過程中，我們進行了大量探索與創新。我們不只是「照本宣科」，而是為 GraphQL 社群在區塊鏈領域補上空缺、做出貢獻。基於我們的技術能力，ArcBlock 應該會是第一個。我們希望發起一場運動，帶動社群開發者使用 GraphQL 來開發 OCAP chain adapter 與 blocklets，建立在我們初步貢獻的基礎上。我們也很樂意與 GraphQL 社群合作，舉辦像 hackathon 這樣的活動，實現雙贏合作。