深入理解 OCAP 实现 (2): 开放链访问协议为何采用 GraphQL

作者: 陈俊 (ArcBlock 团队公关副总裁)

尽管目前全球加密数字货币市场低迷,区块链技术发展在 2018 年却进入了底层公链项目万链齐发的 3.0 时代:针对以比特币、以太坊为代表的区块链 1.0 、2.0 技术充分暴露出的性能低下、用户不友好、功能匮乏、费用高昂、平台“锁定”等痛点,层出不穷的新公链提出了各种技术解决方案。

同样是推动区块链技术普及落地,促进响应消费者需求、应用于各行各业的去中心化应用(DApps)的发展繁荣,ArcBlock 区块基石的思路却与众不同:不是新建一条公链,而是从应用开发的需求出发,利用云技术搭建一个专门为 DApp 开发部署服务的区块链生态平台,帮助开发者去访问连接各种公链,得以更专注便捷地开发 DApp,让区块链应用变得跟今天网页及移动端应用一样简单易用。

搭建这样一个地位相当于 Web 开发里 J2EE、微软的 .Net 框架的云计算平台,开放链访问协议(Open Chain Access Protocol,简称 OCAP) 便成为大厦将起的坚实基础。OCAP 这一开源协议提供一个访问下层区块链的抽象接口层,以帮助开发的应用能够在不同的区块链上工作。“ 类似于在数据应用中的 ODBC 或 JDBC 在和各种不同数据库之间的关系一样,”今年 1 月初发布的 ArcBlock 技术白皮书如此描述,“(DApps)在切换不同的底层区块链、或者使用多条不同协议的区块链的时候,你甚至不需要更改你的业务逻辑代码。”

为帮助开发者轻松访问连接并切换底层公链,ArcBlock 在开发实现 OCAP 时在业界率先采用新一代 API 查询语言 GraphQL ,而非业内普遍采用的 RESTful。

什么是 GraphQL

GraphQL 是 Facebook 2012 年内部开始使用, 2015 年开源的新一代 API 查询语言。在 GraphQL 的官方网站上,他们用代码直接描述了其最主要的特点。

GraphQL

API 开发者仅需要描述 API 的 schema,并为其提供合适的 resolver,客户端就可以很方便地使用 GraphQL query language 来查询数据,而服务器会按照客户端的需求,返回相应的结果。

GraphQL 支持 Query(数据查询)、Mutation(数据更新),以及 Subscription(数据监听)三大类 API,每种 API 都会通过 resolver 返回客户端需要的结果,如下图所示:

GraphQL

GraphQL 里面的 Graph 是有向图,一个查询的每一层都对应一个 resolver,这样一层层 resolve 下来,获取到用户需要的所有数据:

GraphQL

与 RESTful 相比,GraphQL 更高效、强大且灵活,它允许在客户端定义需查询数据的结构,并且从服务器端返回结构完全相同的数据,而不是一大堆返回过多的数据。

GraphQL

GraphQL 对 API 中的数据提供了一套易于理解的完整描述,使得客户端能够准确地获得它需要的数据,而且没有任何冗余,也让 API 更容易地随着时间推移而演进,还能用于构建强大的开发者工具——

首先,当你用 GraphQL 向 API 发出一个请求就能准确获得你想要的数据,不多不少。GraphQL 查询总是返回可预测的结果。使用 GraphQL 的应用可以工作得又快又稳,因为控制数据的是应用,而不是服务器。

GraphQL

其次,GraphQL 查询不仅能够获得资源的属性,还能沿着资源间引用进一步查询。典型的 REST API 请求多个资源时得载入多个 URL,而 GraphQL 可以通过一次请求就获取应用所需的所有数据。这样一来,即使是比较慢的移动网络连接下,使用 GraphQL 的应用也能表现得足够迅速。

第三,GraphQL API 基于类型和字段的方式进行组织,而非入口端点。开发者可以通过一个单一入口端点得到所有的数据能力。GraphQL 使用类型来保证应用只请求可能的数据,还提供了清晰的辅助性错误信息。应用可以使用类型,而避免编写手动解析代码。

Q&A

在 OCAP 上线一个多月之后,ArcBlock 创始人兼首席架构师冒志鸿、研发副总裁陈天,以及 OCAP 项目负责人丁沛灵分别从不同角度就 OCAP 的技术选型一一作答。

为什么 OCAP 实现中选择了使用 GraphQL ?

冒志鸿: 为开发者体验着想,GraphQL 简单直观、容易学习、容易调试、跨平台应用非常方便,而且 GraphQL 适合前端开发,把复杂性隐藏和封装在后端服务器,这就比较适合应用的开发和推广;考虑到我们是支持区块链应用开发的平台,OCAP 需要支持多种不同的底层区块链技术,而目前区块链本身并没有统一的标准和体系架构, 因此需要一种能描述灵活的查询和数据结构的语言, GraphQL 的设计恰好非常适合这种场景;采用 GraphQL 有助于统一处理区块链和传统的数据库、Web Service 之间的衔接和集成,降低开发难度。最后从社区生态方面来看,GraphQL 已经拥有成熟的社区,有丰富的框架、工具等生态可以直接使用。

丁沛灵: 这是 ArcBlock 考虑开发者体验是否良好而做出的选择,采用 GraphQL 作为查询语言,将使得前端查询更加灵活且高效。通常业界采用最多的方式就是提供一组 RESTful API。在服务器端,我们会设置众多 endpoint(终端),每个 endpoint 会接受一些参数,并提供一些服务。这样做的好处很明显,就是对服务器端来说实现也很简单,而且普通用户可以很轻易的通过浏览器访问。最典型的应用就是 BlockCypher、EtherScan。但是缺点也很明显,那就是对开发者不够友好。RESTful API 是基于 endpoint 来发起查询,其组织形式非常松散,会让客户端的代码维护变得非常麻烦,开发者使用起来并不友好。

陈天: 从应用开发的角度来讲,采用 GraphQL 会减轻客户端开发者对数据访问的压力。客户端希望访问的深层数据,比如对比特币的 UTXO(未花费的交易输出)查询请求,采用的 RESTful API 的话,会返回一大堆其实你并不需要的数据——因为你只需要查询交易哈希值,而使用 GraphQL 将大大减轻应用开发者对数据访问的压力。好比使用 SQL 查询数据库一样,使用 GraphQL 查询区块链数据,发起查询行为,传递给服务器端,它将从不同数据源获取数据,构造成一个查询反馈返回,这能够使网络传输数据最优化。客户端需要什么数据,服务器就返回什么数据。

GraphQL 如何帮助 OCAP 实现简单而统一的跨链操作?

陈天: GraphQL 更好地实现了 OCAP 开发链访问层这三个不同等级层 API 的定义。比如,第一层的基础链 API,对于第一版 OCAP 支持的比特币、以太坊都是通用 API,只是针对目标链不一样,通过 GraphQL,非常方便地查询获得不同数据集;在第二层基础链数据 API,不同区块链的不同能力在分化,通过 GraphQL 查询比特币、以太坊是两个不同查询,但其语法结构、用户编写查询(Query)的方式是相似的,一次学习,就能应用在不同链上,开发者不需要太多学习成本,其访问区块链的能力能够轻松地从一条链迁移到另外一条链。并且 ArcBlock 还会提供开发者专用的 OCAP Playground,帮助你利用自动完成功能更轻松地构造查询,大大减轻记忆成本,快速查询到相应结果。

冒志鸿: OCAP 使得支持多种不同的区块链协议成为可能,应用开发者可以从几种不同的区块链协议,不同的节点类型,不同的部署方式中自由选择最合适的方式。开放链访问层定义了统一的 API,然而这些 API 的具体实现则来自于链适配器。

目前区块链技术解决方案,为什么采用 GraphQL 的并不多?

陈天: 相对而言,GraphQL 还是较新的技术,尽管 Facebook 使用了几年。无论对前端还是后端,大多数开发者还是熟悉 RESTful API,很多技术提供商更倾向于通过 RESTful 提供相关服务,有很多成熟的客户端,命令行里 JSON query。但我相信之后会有越来越人采用 GraphQL。其次,GraphQL 在服务器端还有很多门槛。

丁沛灵: 我想一个重要原因是 ArcBlock 和其他公司服务对象不一样。如果开发面向大众、基于浏览器的一个链上数据访问服务,基本会选择传统的 RESTful API,因为你不可能让大众去学习 GraphQL,但是基本上所有人都会打开浏览器,输入网址上网了。

我们如何善用 GraphQL 现有的资源,又能为 GraphQL 社区贡献什么?

冒志鸿: 虽然 Facebook 开源了 GraphQL,但只公开了框架语言,并没有提供具体实现方法,因此我们开发 OCAP 采用 GraphQL,开展了大量探索创新。所以,我们不只是不重新发明轮子的“拿来主义”,而是回馈贡献,为 GraphQL 社区填补区块链领域的空白,ArcBlock 应该是第一家。我们希望带动大家跟进,带动社区开发者采用 GraphQL 开发 OCAP 链适配器、Blocklet(基石程序),产生越来越多的贡献。我们也乐意与 GraphQL 社区联合举办黑客马拉松之类的活动,合作共赢。