深入理解 OCAP 实现 (2): 开放链访问协议为何采用 GraphQL
2018-08-20
深入理解 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 的官方网站上，他们用代码直接描述了其最主要的特点。
API 开发者仅需要描述 API 的 schema，并为其提供合适的 resolver，客户端就可以很方便地使用 GraphQL query language 来查询数据，而服务器会按照客户端的需求，返回相应的结果。
GraphQL 支持 Query（数据查询）、Mutation（数据更新），以及 Subscription（数据监听）三大类 API，每种 API 都会通过 resolver 返回客户端需要的结果，如下图所示：
GraphQL 里面的 Graph 是有向图，一个查询的每一层都对应一个 resolver，这样一层层 resolve 下来，获取到用户需要的所有数据：
与 RESTful 相比，GraphQL 更高效、强大且灵活，它允许在客户端定义需查询数据的结构，并且从服务器端返回结构完全相同的数据，而不是一大堆返回过多的数据。
GraphQL 对 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具——
首先，当你用 GraphQL 向 API 发出一个请求就能准确获得你想要的数据，不多不少。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 社区联合举办黑客马拉松之类的活动，合作共赢。
