Home - chatrbot/wechaty-puppet-simplepad GitHub Wiki

为什么是"SimplePad"?

社区里已经有很多优秀的Puppet可以供大家选择,从最早的PadPlus,到现在优秀的第三方PadLocal,都是非常不错的Puppet实现.而SimplePad和这两者的区别不仅是代码的实现,还有一个是产品出现的顺序.
之前在Wechaty社区群内大家也有听说Wechaty正在进行一系列的Restful风格的接口开发,其实我们一开始就实现了这么一套完备的Http接口,而SimplePad就是基于一套Http的协议(对外开放)接口开发而来. 也是因为有这一整套完整接口作为整个Simplepad的基础,使得整个Puppet技术应用上显得特别的"简单".没有GRPC,没有Protobuf,没有代理.只有简单的Http和Websocket(其实WebSocket也只是为了Puppet的妥协,我们的接口协议提供Http方式的回调).如果想发送一条消息,只需要简单的调用一个Http接口即可,所以的数据流通也是大家最熟悉的Json格式,无需解码,直截了当.
这就是"SimplePad"的由来,简单并不意味着低级.

SimplePad与其他实现的区别

在上面的介绍中,不少同学可能已经看出来了SimplePad和现有Puppet实现的区别,由此我展开讲下相关的优缺点.

• 使用Json,没有使用流行的Protobuf(下称pb)等二进制的协议.pb优点显而易见,节约流量,编码/解码高效,多端统一等等.但这些其实也是因人(项目)而异,对于Puppet这类项目,流量和加/解码(CPU的资源占用)并不会成为项目的瓶颈,而Json的天然优势就是大家都熟悉,简单方便调试,一目了然.孰优孰劣其实并不用过于深究.
• 使用WebSocket,没有使用GRPC.WebSocket是为了实现Puppet而加入的,但因此也比GRPC的整合更为轻量简单.比如您想用Java/Go/Python等来对接我们的API就无需再加入整个GRPC库以及生成对应的pb文件.WebSocket(或Http)+JSON即可完成所有数据通讯.
• SimplePad和PadPlus使用的是类似的服务架构,WeChat实例客户端运行于"集中式"的服务器上,而PadLocal在用户使用的Puppet上增加了一层代理,思路上更为优秀先进一些,实现难度也会大很多.
  但集中式的模式在PadPlus上已经实践已久,实际结果大家也肉眼,只要妥善进行规避其实不会有什么问题.
• 大家关心的数据安全问题,目前所有Puppet方案其实都是无法做到完全不经过服务端.从Padlocal的通讯实现上看其实也是会经过服务端,只是最终在发送消息时候会通过客户端代理的IP发送,从而规避"同一个IP池"的问题,但发送前也会经过服务器的相关协议内容计算.
  所以最终也还是需要"puppet的提供者保持极高的行业自律，而且通过充分的机制保证客户数据的安全性",这也是SimplePad能够长期维护下来的保证.

SimplePad之外

• 完备的Http协议接口.正如前面所说,SimplePad的基础是一整套对应的完整的Http接口,而SimplePad只是其中的一种应用方式.如果想在项目中快速集成WeChat相应能力而又不想依赖于Node(Puppet),Http接口调用的形式就变得更为方便和清晰.在获得Token之后,我们会提供一个完备的后台方便您进行开发操作和管理您的Token.
• 按需购买.有时候您可能只需要其中的某一个功能(比如您只想让机器人定时给你发送一些文本信息),却需要购买完整功能的PuppetToken,这可能让您产生不必要的消耗. 我们在后台提供自助购买API的能力(对应Http接口,非SimplePad),在保证基础功能的前提下多其他接口自助\按需购买,让您省钱省力.

写在最后

对于SimplePad的介绍就这么多,更多玩法和应用需要大家自己探索.

• 快乐编程,幸福生活,SimplePad杜绝任何违法违规的使用方式.
• 如何问题可以提交issues来反馈,我们会及时跟进.