小程序云开发总结

​ 系统分析与设计课程项目终于完结撒花了。我在项目中主要负责小程序的后端部分，在项目规划阶段，我们后端组无意间看到了小程序云开发

• 数据库：一个既可在小程序前端操作，也能在云函数中读写的 JSON 文档型数据库
• 文件存储：在小程序前端直接上传/下载云端文件，在云开发控制台可视化管理
• 云函数：在云端运行的代码，微信私有协议天然鉴权，开发者只需编写业务逻辑代码

看到如此好处，秉持着尝试新鲜技术的精神（懒），我们项目的后端决定采用小程序云开发来实现，从开始感叹它的方便，到中期遇到了种种问题差点放弃改用传统服务器后端，到最后成功做完，这里总结一下经过这几个月的开发，我所理解的小程序云开发的优点和缺点。

优点

• 小程序云开发不需要另外租一个服务器

这个好处还是蛮明显的，小程序开发本身是不需要花费任何钱的，使用云开发服务端的费用也省去，整个开发过程就只有时间成本，完全可以使用云开发小程序做一个人的练手项目。

• 用户无需登入

传统服务器后端确定用户身份是有些复杂的，这就需要根据官方微信小程序的登入流程去走，一系列巴拉巴拉。

而云函数的参数就能直接确定用户的身份：

// index.js 是入口文件，云函数被调用时会执行该文件导出的 main 方法
// event 包含了调用端（小程序端）调用该函数时传过来的参数，同时还包含了可以通过 getWXContext 方法获取的用户登录态 `openId` 和小程序 `appId` 信息
const cloud = require('wx-server-sdk')
exports.main = (event, context) => {
  let { userInfo, a, b} = event
  let { OPENID, APPID } = cloud.getWXContext() // 这里获取到的 openId 和 appId 是可信的
  let sum = a + b

  return {
    OPENID,
    APPID,
    sum
  }
}

这种种的方便确实使得后端开发的工作量大大减少（因为过于方便，所以后面没事做了也参与了小程序页面的开发Orz)

• 方便的日志功能

每一次云函数的调用都能在云开发控制台查看调用日志，在云函数中使用console.log就能输出自定义的日志，在决定后端代码开发规范的时候，我们就决定云函数要在输出关键信息，这样的日志输出方面我们在前端返回没有按照预期的时候，能够还原当时云函数的环境，迅速排查错误。

缺点

• 小程序云开发的服务器不在自己的掌控之中

云开发后端的性能难以保证，在网上也没有找到具体的说明。且云函数、云数据库、云文件存储的每月调用次数是有限制的。且在开发的几个月中，也遇到过偶尔无法调用云函数的情况，这要看腾讯的实力了。要想确保性能还是要有一个自己的服务器比较安心。前期使用云开发试水，获得不错反响后再换成传统服务器也是不错的方案。

• 前端直接使用函数调用的方式，难以遵循RESTful规范

因为是前端直接函数调用，不需要使用URL，只能通过云函数的名字来表示函数的功能，这是面向操作，而不是RESTful所倡导的面向资源。

比如我们获得所有问卷的云函数get_questionnaire，是以动词开头表明是获取，后面才是我们要获取的资源。这样的命名方法导致我们还有fill_in_questionnaire，get_questionnaire_detail的云函数，目前我们只有21个云函数，就已经感觉有一些紊乱了，难以应对大型项目。（PS：项目最后我们想到可以每一个资源有一个Router云函数，再通过参数的调用其他云函数处理，但无奈已经写完了，DDL也到了，没有时间重构）

而根据RESTful设计出来的API就可以是用GET、POST、DELETE方法访问xxx/questionnaire就能够完成各种针对问卷资源的操作，通过服务端的Router将请求导航到不同的处理函数，使得前端的调用比较简单易理解，后端的处理也更有条理，更易于维护。

总结

云开发还是比较香的，当前的小程序完全可以先使用云开发，加快开发周期，如果项目成功，再换回传统的服务器来支持更多的用户以及更好的响应速度和稳定性。