DApps 的全新架构设计:基于 GraphQL 和标准客户端

2020-09-13 19:09:47 84
关于去中心化应用(Decentralized Applications,DApps)的架构,目前我们 ArcBlock 采用了基于 GraphQL 和标准客户端的新型架构设计。 基本思路 1. 后......

关于去中心化应用(Decentralized Applications,DApps)的架构,目前我们 ArcBlock 采用了基于 GraphQL 和标准客户端的新型架构设计。

基本思路

DApps 的全新架构设计:基于 GraphQL 和标准客户端

1. 后端(Serverside)采用 GraphQL 来提供服务,而不是 REST API。

我们曾经发表《开放链访问协议为何采用 GraphQL》、《GraphQL 将为去中心化网络提供动力》等文章介绍了采用 GraphQL 的诸多优点,感兴趣的读者可点击阅读。后端实现 GraphQL 是要比实现 REST api 稍微麻烦一些,但也不是非常难。

2. 很多个小而简单的后端,而不是一个复杂的大后端。

这类似于微服务的概念,也就是不要把各种逻辑全部写在后端逻辑里,而是尽量模块化,各个模块之间松散耦合,越松散、越无状态、越少互相依赖越好。

3. 前端(包括 Web 应用和移动应用)是一个比较纯粹的前端,不依赖后端。

Web 实现上和传统 Web 应用有所区别,因为传统 Web 都是在后端渲染页面的,前端没有什么逻辑,但最近几年流行的 React、Vue、Meteor 等全部是这种前端自带逻辑的设计方式,前端完全通过 GraphQL 连接后端服务来获取数据。这种设计可以让 Web 和移动 App 基本采用完全一致的架构,从而让 Web 应用很容易移动化。

4. 前端来实现完整应用逻辑,后端则没有。

也就是说这个应用表现为一个游戏,还是一个交易所,是由前端来组织多个后端服务来形成,后端只提供了服务,甚至不知道,也不需要知道前端究竟是什么业务。

5. 前端标准化,可以灵活切换不同的后端。

例如,大家会发现电商网站和应用的界面基本都是一模一样的,为什么每家电商都要发布运营自家的 App,而用户要每个地方注册账户,到处填写自己的支付信息呢?理想的电商 DApp 如果采用标准化设计,相同的界面、相同的 App,可以在多家电商平台购物。

其实,很多技术多年发展后,标准化是必由之路。举例而言,任何品牌的电视可以收看任何频道播放的任何节目。任何品牌的汽车都可以加同等规格的任何品牌汽油,加油口也是一样的;车辆可以在任何规格的公路上行驶,无论在哪个国家和地区——这就是标准化的威力。

如何保证用户数据的一致性

DApps 的全新架构设计:基于 GraphQL 和标准客户端

1.由 DID 来保证用户、身份、服务、物品等的一致性,即使跨不同系统,只要这些 ID 保证一致,就不会混淆。DID 的去中心化特征,也保证了大家采用同一套 ID 系统不会有人一家独大,也不会有人占有垄断数据——对照 Facebook、微信这样的平台,大家就明白用户和平台,到底谁说了算。

2.由区块链来保证数据、证据、记录的一致性,以及公开透明、可验证、可追溯。链就像联系各个部件的神经中枢,确保所有参与方不会产生争议。

3.链上的数字资产来实现标准化、自动化支付和结算,以及数字化的权益归属。
4.由智能合约来保证多方合作的利益分配,公开透明。

DApps 设计示例

如果用上述思路实现一个类似于“知识星球”(前身为“小密圈”)应用的话,其设计实现就和传统的 App 有所不同。

假设有开发者打算基于 ArcBlock 平台开发一个类似“知识星球”的 DApp,一个重要的诉求就是这些收费的圈子是充分去中心化的,没有人(包括开发者)可以关闭一个私密的共享圈子。

“小密圈”一开始发展非常迅速,用户非常喜欢,但是不久就被有关部门下架处理——可能有用户在应用内分享违法内容是作出这一封禁决定的重要考量,而因为一小部分不法内容导致整个服务下降,殊为可惜,正所谓“把孩子和洗澡水一起泼掉了”。

一个好的去中心化服务,首先可以有很多节点,每个节点可以制定自己的规则,不符合规则的,节点运营者可以自行处理或者按照当地法律法规处理;不愿受限的用户可以运行自己的节点,或者自发联合起来运行自己的节点。只要这些节点的协议是一致的,采用 DID 机制来分享用户资料,采用链上资产来支付和控制访问管理,那么用户就可以用一个统一的客户端 App (Web、移动应用皆可)来统一访问无数个后端节点。

这样的设计就完美地实现了类似“知识星球”的去中心化的私密分享社群。每个节点制定自己的规则,自主管理内容和法律合规,违规的节点即使被清理关闭,也不会影响整个服务。如果某个节点的服务器宕机,可以简单更换服务器继续认可过去的 DID 和购买记录继续运行,原来的用户一点都不受影响,甚至用户不会知觉节点服务器已经迁移。

开发这个 DApp 的开发者可以制定分配规则。例如所有收益的 10% 归这个开发者;每个节点可以制定规则,例如收入的 15% 归节点运营者;每个收费的分享群主制定自己的价格。如果群主觉得节点收费太贵,可以选择一个便宜的节点,甚至自己运行节点,就完全不需要给节点分成。整个应用的开发者就只需要维护好应用,自己享受分成。应用开发者甚至可以自行制定分成规则,例如收入的 50% 给前端开发者,50% 给后端开发者,如此类推。

来源: ArcBlock 技术社区[1]