DApps 的全新架構設計：基於 GraphQL 與標準用戶端

作者： 冒志鴻（ArcBlock 執行長、首席架構師）

關於去中心化應用程式（Decentralized Applications，DApps）的架構，目前我們 ArcBlock 採用了基於 GraphQL 與標準用戶端的新型架構設計。

基本思路

1. 後端（Serverside）採用 GraphQL 來提供服務，而不是 REST API。

我們曾經發表過《深入理解 OCAP 實作：開放鏈存取協定為何採用 GraphQL》、《GraphQL 將為去中心化網路提供動力》等文章介紹了採用 GraphQL 的諸多優點，感興趣的讀者可點擊閱讀。後端實作 GraphQL 雖然比實作 REST API 稍微繁瑣一點，但並非難事。

2. 多個小而簡單的後端，而非一個複雜的大後端。

這類似於微服務（Microservices）的概念，也就是不要把各種邏輯全部寫在後端程式碼中，而是盡量模組化，各個模組之間鬆散耦合，越鬆散、越無狀態、越少互相依賴越好。

3. 前端（包括 Web 應用與行動應用）是較純粹的前端，不依賴後端。

Web 實作上與傳統 Web 應用有所區別，因為傳統 Web 都是在後端渲染頁面，前端沒什麼邏輯；但最近幾年流行的 React、Vue、Meteor 等全都是這種前端自帶邏輯的設計方式，前端完全透過 GraphQL 連接後端服務來獲取數據。這種設計可以讓 Web 和行動 App 基本採用完全一致的架構，進而讓 Web 應用很容易行動化。

4. 前端實作完整應用邏輯，後端則無。

也就是說這個應用表現為一個遊戲，還是一個交易所，是由前端來組織多個後端服務來形成，後端只提供了服務，甚至不知道，也不需要知道前端究竟是什麼業務。

5. 前端標準化，可以靈活切換不同的後端。

例如，大家會發現電商網站和應用的介面基本都是一模一樣的，為什麼每家電商都要發布營運自家的 App，而使用者要在每個地方註冊帳戶，到處填寫自己的支付資訊呢？理想的電商 DApp 如果採用標準化設計，相同的介面、相同的 App，可以在多家電商平台購物。

其實，很多技術發展多年後，標準化是必經之路。舉例而言，任何品牌的電視都可以收看任何頻道播放的任何節目；任何品牌的汽車都可以加同等規格的任何品牌汽油，加油口也是一樣的；車輛可以在任何規格的公路上行駛，無論在在哪個國家和地區——這就是標準化的威力。

如何保證使用者數據的一致性

DApps 設計示例

如果用上述思路實作一個類似於「知識星球」（前身為「小密圈」）的應用，其設計實作就與傳統的 App 有所不同。

假設有開發者打算基於 ArcBlock 平台開發一個類似「知識星球」的 DApp，一個重要的訴求就是這些收費的圈子是充分去中心化的，沒有人（包括開發者）可以關閉一個私密的共享圈子。

「小密圈」一開始發展非常迅速，使用者非常喜歡，但是不久就被相關部門下架處理——可能有使用者在應用內分享違法內容是作出這一封禁決定的重要考量，而因為一小部分不法內容導致整個服務被關停，實屬可惜，正所謂「連同洗澡水把孩子一起倒掉了」。

一個好的去中心化服務，首先可以有很多節點，每個節點可以制定自己的規則，不符合規則的，節點營運者可以自行處理或按照當地法律法規處理；不願受限的使用者可以運行自己的節點，或者自發聯合起來運行自己的節點。只要這些節點的協定是一致的，採用 DID 機制來分享使用者資料，採用鏈上資產來支付和控制存取管理，那麼使用者就可以用一個統一的用戶端 App（Web、行動應用皆可）來統一存取無數個後端節點。

這樣的設計就完美實作了類似「知識星球」的去中心化私密分享社群。每個節點制定自己的規則，自主管理內容和法律合規，違規的節點即使被清理關閉，也不會影響整個服務。如果某個節點的伺服器當機，可以簡單更換伺服器並繼續認可過去的 DID 和購買記錄繼續運行，原本的使用者一點都不受影響，甚至使用者不會察覺節點伺服器已經遷移。

開發這個 DApp 的開發者可以制定分配規則。例如所有收益的 10% 歸這個開發者；每個節點可以制定規則，例如收入的 15% 歸節點營運者；每個收費的分享群主制定自己的價格。如果群主覺得節點收費太貴，可以選擇一個便宜的節點，甚至自己運行節點，就完全不需要給節點分成。整個應用的開發者只需要維護好應用，自己享受分成。應用開發者甚至可以自行制定分成規則，例如收入的 50% 給前端開發者，50% 給後端開發者，以此類推。

來源： ArcBlock 技術社群