一、写在前面

我比较喜欢做微信生态的解决方案，给企业或个人提供一些技术方案和应用形态选型的咨询。最近跟一些朋友聊天，他们在各自的工作岗位中，随着工作熟悉就会自然而然有很多能提升工作效率的点子。

有些人喜欢用文档、问卷、表单等 SAAS 应用捏合一个自己的效率集，一般能满足很多场景；但还有一些场景可能没有合适的 SAAS 应用，于是就想搞个小程序，然后来问我怎么做比较合适。

“小程序一定程度上降低了开发者搭建应用的门槛，做一个小程序相比其他的产品形态效率更高，落地更快。”，这个观念在这几年的发展中越来越深入，有很多不是软件行业的朋友都能提出小程序这种想法。

通过简单的代码，做一个满足自身小场景的小程序，并不是很难。有一定的数理基础，配合社区的入门教程很容易上手。上手门槛已经降低到中小学生都能触及到的程度了，微信还针对的搞了个少年挑战赛。

完整的闭环一个应用，单纯用小程序做个前台还是不够的，很多情况下我们需要有后台做管理支撑。

比如一个登记小程序，除了小程序能够提供登记信息填写外，还需要一个后台能够承载管理人员做状态扭转或者其他的后备工作。

一般这种情况下有几种解决思路：

1.  在小程序中编写管理页面，通过用户 openid 来指定仅管理员可见。

2.  通过接口对接企业微信或者其他 SAAS 平台的 webhook 能力来组合管理。

3.  搭建一个可操作的管理后台，有细粒度的权限管控。

接下来我主要分析一下这几种方式的实现和利弊，你可以根据自身的需要有针对的选型。

二、后台方案对比

1.  在小程序中编写管理页面，通过用户 openid 来指定仅管理员可见。

• 实现方式：编写单独的管理页面，或者在业务页面中嵌入一些管理按钮，每次加载时，通过后端比对 openid 返回给小程序端是否可以展示管理页面或内容。
• 方案优势：小程序开发难度，低门槛，实现简单。
• 方案劣势：管理权限的授予以及可靠性维护太差，浪费资源。

○ 管理者的身份需要设计机制去确认（手机号关联or访问记录）

○ 管理页和内容占用小程序包资源，影响普通用户的使用体验

○ 正常用户访问也会判断管理员逻辑，浪费数据库读资源（硬编码则维护难度增大）

○ 管理接口与业务接口有混用的风险

这种实现是大部分初入者首选的，因为微信用户体系比较完备，可以通过 openid 来确定一个微信用户。在用户打开小程序时，服务端判断用户身份是否是管理员，如果是的话返回一些信息给小程序，小程序对应的展示相关管理页面内容或入口。

劣势也是非常明显的，由于管理逻辑与业务逻辑都集中在小程序通信，会在身份判断，业务处理上有更多的无效的数据库读请求，浪费资源。

2.  通过接口对接企业微信或者其他 SAAS 平台的 webhook 能力来组合管理。

• 实现方式：暴露一些接口，然后使用企业微信的机器人或其他工具对接暴露的接口，实现通过消息或者点击驱动接口完成一些配置。比如访问接口地址填写一些特定参数来实现状态扭转（https://www.example.com/api/status?id=10001&type=success&key=1212）
• 方案优势：只需要提供接口即可，几乎没有前端的开发成本。
• 方案劣势：可读性比较差，并且有被攻击的风险，接口安全需要下功夫。

○ 可读性比较差，无法可视化，但可通过其他工具加以改善。

○ 由接口的参数驱动，权限校验为明码，容易泄露。

○ 应对管理场景有限，无法应用到复杂的管理操作（如上传图像或批量处理）

这种方案一般用于非常简单的管理场景中，比如就只针对一个事项做状态扭转，发起一个批处理的任务，发送通知等。完全由接口来驱动完成。但权限管控只能通过参数来明码输入，或者通过结合 saas 工具，来利用其调用时的 header 信息来做权限判断。

3.  搭建一个可操作的管理后台，有细粒度的权限管控。

• 实现方式：搭建独立的 WEB 后台（或APP ），来统一设计用户管理权限，以及搭建各种业务的管理流程。尽量不在接口层面与业务端有交集，仅做数据层面的处理和互通。
• 方案优势：灵活度大，可以实现任意后台管理场景，并且可以接入丰富的权限管控。
• 方案劣势：搭建难度大，处理的开发流程复杂，可能需要重新设计一套用户体系。

○ 搭建难度可能远远超过小程序前台，需要考虑投入是否值得。

○ 根据所需可能要对接不同的用户登录体系，比如用户名密码+微信登录+邮件登录。

这是一个标准的方案，业务后台页面的构成和功能设计需要根据自己的业务场景来单独设计，其用户群体为业务管理者。在功能实现上既可以有数据库的增删改查，也可以有外部平台的调用（比如微信支付分账，发起退款，发送邮件通知等）。作为开发者在搭建后台时，遇到的实现点和难度可能都是高门槛的，所以需要一定的技术积累，并充分理解用户群体（业务管理员）的工作流程。

三、微信在后台方面做了什么？

为了让开发者在做个小程序这方面的门槛降低，从设备端到用户体系，从单机存储到联网同步。微信团队围绕小程序开发的各个环节提供了很多产品和服务形态，其核心目标就是让开发者做小程序的门槛变得更低。

比如微信云服务，Donut 开发平台，通过提供云端资源和平台能力，在一些方面多做一些，让开发者少做一些。

在业务后台这个方面，实现上脱离小程序本体，但是从业务经营者角度来看，又是小程序业务不可或缺的一环。所以微信针对业务后台这方面也提供了解决方案：

云后台是微信最近上线的一个能力，主要面向小程序或公众号 H5 场景的业务开发者，沉淀常见的后台管理场景；通过提供丰富应用模板、开放数据接口、灵活管理权限等功能，降低开发者搭建后台的成本，提升开发效率。

通俗来解释的话主要就有 3 个亮点：

1.  丰富的模板应用和灵活的搭建驱动。

• 除了我们常需要的 CMS 内容管理，还提供常见的商品管理，订单管理，数据分析，支付管理等等。
• 如果这些模板不能满足你的场景或者场景没覆盖全，你可以直接去编辑应用，用低代码编辑器来搭建自己心目中的理想应用。

2.  可以自由定义的数据接口和外部平台连接

• 云后台自动携带一个中心化数据源，并提供完备的数据操作接口。
• 如果你自己有自建的数据源，可以在云后台自由配置连接，直接对接到各个后台应用
• 提供针对微信开放平台、微信支付平台的现成连接接口，只需要配置令牌信息就可以直接用，不需要花时间再做调试。

3.  提供灵活的用户权限管理，细粒度控制

• 云后台内置用户权限体系，可以针对不同业务管理场景创建角色，并赋予特定的应用可见和可操作权限。
• 提供丰富的认证源，比如微信扫码登录，或者自建的认证源。

其中我觉得对初学者友好的一点是，如果你只开发了一个单机小程序，还没有做云端接入。云后台由于有中心化数据源，也就意味着你不需要自己搭建后端服务了，直接使用云后台暴露出来的接口调用就好。

有关于云后台的具体使用细节的动态体验，我会在后面单独开一篇文章，发布后会更新到这里，如果感兴趣可以关注下。

四、总结

如果你目前正在为业务后台的搭建烦恼，或者有计划升级你的后台形式，不妨可以花点时间体验一下，具体请参见云后台文档。

如果你有小程序前后端开发的疑点或者寻求方案，可以联系微信云服务的架构师。

关于本文中提出的观点和内容，如果你有其他补充和意见，欢迎在文章下留言一起探讨～