写在前面
最近打算入坑小程序开发，找了一点教程自学。今天在github上看到这个项目：Wafer，总结下来，该项目提供了简化小程序后端开发的两个服务：会话服务--简化小程序登录开发流程和用户管理），信道服务--简化websocket开发流程；另外就是介绍了腾讯云官方的一站式部署小程序的服务.
这是官方介绍：
Wafer 是腾讯云面向广大开发者提供的小程序开发全栈资源套件，套件提供小程序会话管理服务和 WebSocket 信道服务，部署方式具备良好的弹性伸缩能力，可以快速应对业务的爆发增长，同时具备较低的开发门槛。
这是介绍Wafer由来的文章：Wafer文章
现将我认为有收获的地方做下摘抄和个人评价， 最后再谈一下我对于使用这个方案的总的看法。由于本人水平有限，有讲的不对的地方，还请原作者和各位读者指正。
Wafer概述：
- 作者初期专门实现了一个
会话管理sdk来管理小程序的用户会话。但后期重构成了一个单独的会话服务，理由是：
但是弊端在于，该能力只能被 Node 开发者使用，其他语言的开发者无法使用。同时，因为小程序的 appId 和 appSecret 存放在外网可以访问的服务器上，也有一定安全性问题。会话服务和我们的业务耦合在一起，也给后续的横向扩展带来了麻烦。
个人认为这些理由不足以说服我将这个会话管理sdk抽象成一个单独的服务。
第一：前期sdk只有nodejs版本，那么说明后端服务是用nodejs开发，本就不需要别的语言版本。如果需要开发其他语言版本，也只是开发一次就一劳永逸的事儿（该语言上），工作量完全可控。而且抽象成一个单独服务，带来的是复杂度和维护成本的增加（要多维护一个服务）。
第二：小程序的appId和appSecret保存在外网的安全性问题，也不是抽离成一个单独的服务的理由。解决方法首先是服务器安全等级提高，做好权限管理，最大限度的避免黑客入侵。另外就是可以从其他管理重要数据的服务中获取，而不是硬编码到代码中。如果仅仅为了安全性而抽离出一个服务，未免过于小题大做。
第三：关于弹性扩展的问题。这一条我觉得有道理，但如果业务服务器具备弹性的能力的情况下，拆分后能带来多大的扩展能力呢？而且是在增加通信成本的情况下，我持保留意见。
反而，我认为抽离出单独服务，以下的考虑才是最重要的：
那就是：解耦。当服务规模增加到一定程度，单体服务无法承载最大的访问量时，将其拆成一个个单独服务，便于每个服务单独管理，具有良好的扩展性。这也就是当前盛行的微服务概念。但前提是你的项目规模已经达到了一个很大的量级----对于一般中小团队，过早的做服务拆分我认为反而会增加复杂度，得不偿失。
-
作者实现了一个pass服务：信道服务，用于websocket通信。
建立websocket，来自原文
websocket通信，来自原文
理由是：
但是由于客户端的实现是自行实现，和 Socket.IO 的后端配合可能会出现不可控的情况。同时，我们发现 WebSocket 的后端实现门槛比较高，并且进行横向扩展的话会更加困难。
我不太理解作者团队为什么要选择用socketio，而不是websocket，另外后端应该有第三方websocket库的，没必要自己实现，也就不存在说实现门槛过高的问题了。还是那个理由更能说服我吧：为了解耦，为了微服务化。
-
最后作者推荐了腾讯云的一站式微信小程序部署方案：
一站式部署，来自原文
这个一站式方案确实是能提高开发效率的，好多之前需要手动部署的工作都被自动化了，将来有机会可以尝试一下。
个人看法：
在目前的阶段，小程序的开发还属于初期阶段，各种周边的开发环境还不是很完善。所以才有了像Wafer这种项目，目的是想为开发者提供便利，让开发者更专注于业务开发上，出发点是好的，值得称赞！
但是，对于大部分团队，尤其是中小团队来说，个人认为这又不是很实用，因为你是要衡量投入产出比的，在项目还没有预见到是否有那么大访问量的情况下，初期就接入这种第三方服务，无形中给团队增加了复杂度，结果大概率是不划算的。
小程序的开发，一般都还是一些规模不大的项目。先做成一个mvp产品（最小化可行产品），快速上线，快速验证，快速迭代，这才是最重要的。
当然了，我从这个方案中也有收获：
- 了解了小程序会话管理相关流程，感觉后端开发方面跟一般的会话管理思路大致一样，主要是前端方面了解到是小程序是没有cookie概念的，也没有dom操作。通过code，appid，appkey获取seesion_key作为用户凭证，一般有效期是30天。
- 作者对于安全性方面的考量值得学习。比如：用户session_key封装一层再返回给前端，appid和appkey不放到外网服务器上。
- 解耦合的思路，从硬编码到单独实现为一个会话sdk，再到单独抽离出来作为一个服务。
- 将工具化，自动化做到极致，能交给机器完成的事情，就不要让人去做了，不仅容易出错，还耗费时间。当前火热的人工智能，目的不也是用机器代替人嘛。
- 架构不是一朝一夕的，是时刻在演变的。没有最完美的架构，只有最合适的架构。在初期不宜把项目架构设计的过于复杂，可能hold不住，即使hold的住也付出很大代价。尤其是小团队。
最后不得不说，这个方案自从在几个月前发布到github之后，貌似就没有再更新过，issues也无人管理。对于这种项目，使用起来还是要慎重的，当遇到坑时怎么办，靠自己吗？自己能不能搞得定，搞的定又会不会花非常多的时间呢？这太多未知了，所以，我个人目前还是不太可能会选择这个开源项目的。
