小程序销售后台 第1篇
○ 可读性比较差，无法可视化，但可通过其他工具加以改善。
○ 由接口的参数驱动，权限校验为明码，容易泄露。
○ 应对管理场景有限，无法应用到复杂的管理操作（如上传图像或批量处理）
这种方案一般用于非常简单的管理场景中，比如就只针对一个事项做状态扭转，发起一个批处理的任务，发送通知等。完全由接口来驱动完成。但权限管控只能通过参数来明码输入，或者通过结合 saas 工具，来利用其调用时的 header 信息来做权限判断。
小程序销售后台 第2篇
○ 管理者的身份需要设计机制去确认（手机号关联or访问记录）
○ 管理页和内容占用小程序包资源，影响普通用户的使用体验
○ 正常用户访问也会判断管理员逻辑，浪费数据库读资源（硬编码则维护难度增大）
○ 管理接口与业务接口有混用的风险
这种实现是大部分初入者首选的，因为微信用户体系比较完备，可以通过 openid 来确定一个微信用户。在用户打开小程序时，服务端判断用户身份是否是管理员，如果是的话返回一些信息给小程序，小程序对应的展示相关管理页面内容或入口。
劣势也是非常明显的，由于管理逻辑与业务逻辑都集中在小程序通信，会在身份判断，业务处理上有更多的无效的数据库读请求，浪费资源。
小程序销售后台 第3篇
我比较喜欢做微信生态的解决方案，给企业或个人提供一些技术方案和应用形态选型的咨询。最近跟一些朋友聊天，他们在各自的工作岗位中，随着工作熟悉就会自然而然有很多能提升工作效率的点子。
有些人喜欢用文档、问卷、表单等 SAAS 应用捏合一个自己的效率集，一般能满足很多场景；但还有一些场景可能没有合适的 SAAS 应用，于是就想搞个小程序，然后来问我怎么做比较合适。
“小程序一定程度上降低了开发者搭建应用的门槛，做一个小程序相比其他的产品形态效率更高，落地更快。”，这个观念在这几年的发展中越来越深入，有很多不是软件行业的朋友都能提出小程序这种想法。
通过简单的代码，做一个满足自身小场景的小程序，并不是很难。有一定的数理基础，配合社区的入门教程很容易上手。上手门槛已经降低到中小学生都能触及到的程度了，微信还针对的搞了个少年挑战赛。
完整的闭环一个应用，单纯用小程序做个前台还是不够的，很多情况下我们需要有后台做管理支撑。
比如一个登记小程序，除了小程序能够提供登记信息填写外，还需要一个后台能够承载管理人员做状态扭转或者其他的后备工作。