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）的開發範例，在結尾處提到二者的代碼行差別：

This ±10x reduction in the number of lines of code when Go and Composer solutions are compared is fairly consistent across several samples.

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」並給出了下面的評語：

... However, the programming abstraction of chaincode is relatively low level given it manipulates the state of the ledger directly. Moreover, it always takes a lot of time to set up infrastructure before writing the first line of blockchain code. Hyperledger Composer, which builds on top of Fabric, accelerates the process of turning ideas into software. Composer provides DSLs to model business assets, define access control and build a business network. By using Composer you could quickly validate your idea through a browser without setting up any infrastructure.

最後，請你們記住：即便Composer下降了開發的門檻，但仍是要記得認真學習Fabric文檔喲！