Hyperledger Fabric周周记：Composer

在上周周记的结尾，我曾经说过本周要介绍Fabric的开发和应用。按照最开始的写作计划，我打算讲讲两种开发模式：直接使用Fabric API和利用Composer框架。可在通读完Composer的文档之后，我立即取消了原定计划，直接介绍Composer。

选择工具A而不是B一般情况下理由都很直接：简单易上手。以我个人为例，在翻完Fabric的文档之后，虽然对于Fabric的架构和组件了然于胸，但对于如何开发，其实还是很模糊的。

为什么会这样？

有两个原因：

• 文档本身给出的开发范例（fabric-samples）缺乏一个系统性的介绍。所谓系统性，说白了就是教科书性质的介绍，由一个简单的例子开始，层层递进，最终让读者全盘掌握。就当前的文档来说，这一任务显然没有达到。
• 缺乏聚焦，正如这篇Composer幻灯片（第四页）介绍的，有太多东西要操心了，对于真正需要关心的东西（业务逻辑）反而没有突出。

Composer恰好非常好的弥补了Fabric文档中这两个缺陷，从其文档构成可以很明显的看出来：

1. 给出Composer的整体性介绍
2. 手把手教会大家如何完成安装
3. 给出一个Hello World级别的例子
4. 如何进行单元测试
5. 如何部署到真实的Fabric环境

这种方式是我最喜欢的，对于开发者来讲，他能很快建立起整体印象，并且树立起信心。

当然，文档好并不足以吸引开发者成为粉丝。让其成为开发首选的理由只有一个：对开发者友好。

Composer的开发者友好性表现在以下几个方面。

1. 良好的抽象

Chaincode是Fabric开发的核心，但看过了例子之后，说真的，很容易让开发者打退堂鼓。因为太底层了！让人有一种回到用Servlet开发Java Web应用的感觉。

Composer在这一点上做得很好，它的Runtime内置了通用的Chaincode。使用它开发根本不会感到Chaincode的存在。而且整个过程几乎跟你开发一个普通的CRUD Web应用无异！在开发者看来，他就是在写普通的JavaScript函数。

这篇文章给出了两种方式（Chaincode和Composer）的开发范例，在结尾处提到两者的代码行差异：

2. 统一的工程化体验

实际的开发不是书上的简单例子，而且涉及多人，如果没有良好的开发规范，很难产生好的结果。从Fabric文档中，你无法看出一个区块链应用的项目工程应该是什么样子，只能看到一个个零散的代码文件。显然无法满足工程上的要求。

就一个Fabric区块链项目来讲，它包含：

• 存储于账本上的Asset
• 操作Asset的Chaincode
• 访问Chaincode的Client App
• 应用相关的权限和成员

Composer非常完美地给出了解决方案，将整个开发过程分成3部分，每一部分都有对应的命令行工具，提供统一的开发体验：

1. Business Network，业务逻辑，其中包括以下组件：

   • asset model，存储于账本上的Asset，其过程跟设计数据库的表没什么两样。
   • transaction function，对应Chaincode中的各个方法，但对于开发者来讲完全透明。
   • acl文件，权限定义。
   • query，命名查询，供transaction function调用。

2. Rest Server

   • 将发布到Fabric的Business Network暴露成Restful API，供外部调用，完全语言中立。

3. Client App

   • 严格来讲，这一步并非必要，因为既然上面已经有了语言中立的API，理论上可以用任何框架来开发相应的Client APP。但Composer提供了一个基于Angular的模板帮助加速这一过程。

怎么样，这个过程是不是非常眼熟？通过开发框架固化的开发过程可以让开发人员更快的上手，并且统一在相同的“big picture”之下。并且，上述的各个组件对于有经验的开发者并不陌生，有助于快速理解。

大家可以在文档中的这个例子中看到完整的过程。

3. 内建测试的支持

即便是水平再烂的开发，他也希望能验证一下自己写的东西才好意思交出去。然而，对于Fabric应用来讲，这可不是件容易的事情，因为部署太繁琐了。

Composer再次拯救了开发！

Composer内置的runtime为测试提供了良好的支持，由于良好的抽象，这个runtime既可以是实际的Fabric，也可以是一个内置的Node.js进程。而后者则是为测试而生的。更好的是，这一切完全对开发者透明，开发的上层代码完全不需要改动。

对于上进心更强，想要实现自动化测试的同学，这里有一个例子可以参考。

4. 便捷的CLI工具

相比起Fabric零散的命令集合，Composer提供了便捷的CLI，统一了开发、管理和运营任务。开发者可以利用它方便的实现：

• 应用打包和部署
• 应用脚手架生成
• 环境管理

让开发更加聚焦于手头的任务，而不是为了准备工作而分散太多精力。

前面说了Composer的那么多好处，接下来说说Composer的局限性。就目前的文档来看，我没有看到如何用它来开发System Chaincode的例子。而且，我怀疑当前的版本并不支持。因此，假如你像要开发的System Chaincode，Composer可能并不能满足你的需要。而这一任务应该算不上一个大众型任务。

或许你会奇怪，为什么我没有展示一个实际的例子来证明我说的这些好处。这只能怪Composer的文档写得太好了，基本是傻瓜式教程，按照它的步骤，基本不会出现什么问题。既然是这样，干嘛还要花时间在这个上面呢？

说到底，本文的目的只有一个：用Composer来开发未来的Fabric应用，不要再自虐了！同时，最新一期的Thoughtworks雷达也将其列为“TRIAL”并给出了下面的评语：

最后，请大家记住：即使Composer降低了开发的门槛，但还是要记得认真学习Fabric文档哟！