熟悉Web開發流程的同學應該都清楚，開發一個完整的服務器後端，無非要弄清楚幾樣東西。
1. 請求如何接入？是http，restful, 還是rpc？
2. 應用邏輯寫在哪裡，怎麼寫

3. 數據如何存儲？用什麼數據庫？
4. 當前服務如何調用其它服務（高級，異步）

將此模式應用到Substrate 上，官方給出瞭如下結構圖。在這個圖中，Off-chain workers 起到了非常重要的作用。

筆者通過對substrate 的深度分析，在這裡給出上圖的一個細化圖，基於此圖，採用substrate 進行Web3.0 的開發就就豁然開朗了。

區塊鏈應用開發更加複雜一些，因為涉及到鏈上鍊下不同部分的操作。對上圖Substrate Application Structure 的解釋如下：

1. 外界使用Json RPC 與substrate node 進行交互

2. （幾乎）所有對鏈上狀態的修改，都應該使用transaction 提到到Runtime logic 中進行處理

3. Runtime logic 對Runtime 的Storage 具有完全的讀寫能力。對Offchain Storage 具有寫能力
4. Substrate node 能直接對Offchain Storage 進行讀寫

5. Offchain Workers 能直接對Offchain Storage 進行讀寫，只能讀Runtime Storage 中的東西

6. Offchain Worker 可以提交新的交易來實現對鏈上狀態的更新

7. Offchain Worker 可以請求外部服務，獲取相應的數據回來，（異步）更新鏈上狀態或者本地存儲

8. Substrate node 可以通過Runtime API 機制對鏈上狀態進行讀取，也可以傳參數進Runtime logic 以更靈活地讀狀態

9. 鏈上狀態的變更，會生成event，發送到substrate node 中，經由rpc 被外界監聽到
基於Substrate 這種清晰的結構，我們可以設計一些不同的 Web3.0 應用的編程範式。比如其中一種是：

1. 所有修改狀態的操作，都提交到鏈上處理。但是鏈上不一定存儲所有信息，可以通過Offchain Indexing 存一部分到local storage (offchain storage)
2. 所有查詢狀態的操作，可以只通過local storage 查詢。或者鏈下與鏈上storage 相結合的方式查詢（鏈上存儲代價較大，而鏈下存儲代價小）。
3. Offchain 層可以作為與外界服務完全隔離的緩存層。使得鏈上邏輯，只需要專注於substrate 體系本身。而不受外部接口和數據的影響
還可能出現一些瘋狂的玩法，比如：

● 直接使用substrate node 和offchain storage, offchain worker 部分，實現一個傳統的應用服務。完全跟區塊鏈沒有關係

● 所有交易先提交到offchain storage 中，由offchain worker 監聽後，來代理提交交易？ ：P

不過現在Offchain storage 的能力和接口還比較弱。作為kv 數據庫，功能比redis 之類差太遠。而如果能有一層sql 數據層就更完整更好用了——能否嵌入一個sqlite 進去呢？