Substrate应用开发解析：Subsocial架构解析（上）

前言 本Substrate应用开发解析系列，主要选择优秀的面向具体应用的项目进行解析，总结经验，整理模式，给其它项目方以启示，并将Substrate的应用推广到更多场景。

本次我们选择Subsocial项目进行解析。

Subsocial项目介绍 Subsocial自己的一句话介绍是：“An open platform for decentralized social networks and marketplaces. It's censorship-resistant and has built-in monetization methods. Built with Polkadot and IPFS tech stack.” 一个面向分布式社交网络和市场的开放平台。它抗审查，并内置铸币方式。它构建在Polkadot和IPFS技术栈上。

Subsocial是目前Substrate生态历史最久，（相对）最成熟的社交网络应用。你可以把它想象成分布式的Reddit、Blog、Medium。使用Subsocial，你可以为每个社交类应用跑一个链。

据其官网所说，为何要选择Subsocial，是因为当今的社交网络有如下问题，而Subsocial致力于解决这些问题： - 全球审查 - 不公平的变现方式 - 网络效应的垄断 - 缺少可定制性 - 算法独裁

Subsocial项目将自己定位为一个社交网络平台，同时也是一个社交网络框架。用户可以用subsocial启动自己的社区网络，并（理想情况下），以平行链的形式接入未来上线的Polkadot网络。

Subsocial的仓库项目情况 Subsocial官方仓库在https://github.com/dappforce。其下有几个主要的仓库： 1. Subsocial-node：substrate开发的链节点 2. Subsocial-offchain：subsocial链下枢纽，处理链下业务 3. Subsocial-js：与subsocialnode打交道的js库，负责rpc通信及上层的封装 4. Subsocial-web-app：前端UI 5. Subsocial-docs：相关文档 6. Subsocial-flutter：fluttersdk，用于手机端UI 7. Subsocial-starter：启动脚本，用于启动和运维

整个Subsocial工程，除了链节点之外，还由好几个组件共同组成。下面一节会解释这些组件之间的关系。

Subsocial的架构图及解释 Subsocail官网给出的分层架构图如下：

[图片]

上图中，只有Substrate和IPFS层是协议必备组件，其它部分是可选的，但可用于优化整体的交互体验。

经过对Subsocial结构深入分析，我们整理出如下总体架构图：

[图片]

各个组件的功能如下： - IPFS组件用于存放Subsocial平台的图片文件和所有内容数据； - Subsocialnode存储各种模型和其索引； - Subsocialoffchain是各种链下逻辑的枢纽； - PostgreSQL用于存储feed，notifications,activities信息。访问这些信息不走ipfs和Subsocialnode； - ElasticSearch用于搜索spaces,posts,comments,profiles信息。搜索请求，直接访问这里；

写的过程（以创建一篇Post为例，假设你已经登录）： 1. 用户WebApp发起请求到SubsocialOffchain，运行ipfs/add，将Post整个结构添加到ipfs服务器中（如果Post内容中包含image，则是先在浏览器中请求ipfs/addFile，再将返回的文件hash值放入Post结构中）； 2. 从ipfs正常返回后，SubsocialOffchain将ipfs生成的Posthash值（也就是cid）返回给WebApp； 3. WebApp将cid信息与Post的其它结构信息一起，向Subsocialnode发起一个transaction。这时会调起你的Polkadot浏览器插件进行签名。每发起一次成功的交易，会扣除掉你的账户中的一部分金额（注册后会有水龙头给你一部分SUBtoken）； 4. 交易执行后，会从Subsocialnode中抛出Event，SubsocialOffchain会监听Subsocialnode，并获取到这些Event，然后进行处理，并将Event中的相关信息写到PostgreSQL和ElasticSearch中； 5. 这样写过程就完成了。

读取一篇Post的过程： 1. 对于刚创建的Post，其cid会缓存在WebApp，于是用户发起ipfs/get请求到SubsocialOffchain； 2. SubsocialOffchain直接去ipfs服务器上取回数据（是一个Json），返回给用户； 3. WebApp将Json数据渲染出来；

首页加载过程： 1. 用户访问https://app.subsocial.network/，加载静态资源到Browser； 2. WebApp建立rpc.subsocial.network连接，使用jsonrpc协议，这个连接直接连接到Subsocialnode上，通过Substrateruntimeapi获取信息； 3. 通过rpc从Subsocialnode获取一些初始信息（链上的信息）； 4. 通过调用20次state_getStoragerpc方法从Subsocialnode中取出20条Post索引信息，返回回来是编码后的数据； 5. WebApp解码，得到最近20篇Post的cid； 6. 发请求到https://app.subsocial.network//offchain/v1/ipfs/get，这个请求经SubsocialOffchain节点转发到ipfs节点，从ipfs节点取回这20篇文章的json结构； 7. 这些json数据经SubsocialOffchain中转后，返回给WebApp； 8. WebApp对这些数据进行前端渲染； 9. 还有一些其它数据请求，也是类似的模式； 10. 页面呈现完毕。

由上图结构可以看到，SubsocialOffchain会启动一个WebServer，并同时维护4个连接（不全是长连接）： 1. 与IPFSnode的连接 2. 与Substratenode的连接，订阅substrateevent 3. 与Pgdb的连接 4. 与es的连接

以上就是Subsocial这个项目的总体架构。

一些选择 由于Subsocial项目立项时间比较早。在代码里面： - Runtime尚未更新到v3写法 - 没有使用substrate提供的offchainworker和offchainstorage特性

一些不足 从架构图可以看到，Subsocialoffchain这一个独立的nodejs项目占据整个系统的一个核心位置，而其是需要独立运维的，并没有纳入Substratenode一起实现自动去中心化。在这一点上，显得不是那么Web3.0，还有改进空间。

前端Js体验不够好。加载数据慢，js执行有时会卡死浏览器。

数据加载上的一些优化点，比如：首页一次性直接加载了最近20条Post信息，是全文，没有做摘要