知晓云在上周推送了 Web SDK 的内测报名。因为我的小程序『戏词』的缘故,我在第一时间便提交了申请。前几天通过审核后,就赶紧地试了起来。在把『戏词』网页端的内容获取基本完成后,来说说这个 Web SDK 吧。

这篇还是主要谈下这几天的使用体验。关于小程序『戏词』之后再写篇详细的吧,不过这里先简单提一下。

戏词是我在去年 2 月份上线的小程序,起初的功能只有一个,那就是能把台词的截图方便快速拼接成一张。下半年上线了新版本,新增了任意图片添加自定义字幕的功能。并且使用知晓云 BaaS 作为数据存储,增加了『一刻』『一期』功能用于拼图分享。

其实网页版本的『戏词』在刚上线新版本的时候就有用户在提。但是因为时间安排,只能让这个需求一直在 TODO 里面静静躺着。由于微信对个人版的小程序限制非常严格,用户没办法在小程序内做提交自定义内容的动作。而且新版本伤心后随着投稿数的增加,靠用户添加客服微信后发图,再由我整理图片上线的做法效率实在是低得惊人。所以这件事情的紧迫性也不断地提高。

在这个 Web SDK 出现之前,知晓很贴心地提供了 Open API,让开发者可以在小程序以外的程序也可以继续访问其数据库,照着官方的例子就能做好。我就搭了一套 Express 作为 API 供网页版使用。Open API 的问题是参数的设置比较麻烦,尤其是设置查询 where 的那里,参数名和对应的格式,最后还要 JSON.stringify,像我这种经常忘东忘西的,经常是出了问题再去找文档再以一比对真的是觉得人生就这么废掉了……【当然可以自己多封装一层再调用,不过因为后面听说有 Web 版的消息了,自己就没再继续封装 API 了。

Web SDK 的出现,无疑给了网页的快速开发注入了新的动力。从调用方式上到返回的数据结构都与小程序端保持一致,跨平台的友好性满分。

我的实践是封装一个用于页面调用接口的 api.js 文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import zhixiao from "minapp-sdk";
zhixiao.init('clientId');

export default getSpecials = (size, page = 0) => {
let Special = getTable('special');
return Special
.limit(size)
.offset(size * page)
.orderBy('-created_at')
.find();
};

export default getSepcial = id => {
let Special = getTable('special');
return Special.get(id);
}

function getTable(tableName){
let table = null;
switch(tableName.toLowerCase()){
case 'special':
table = new zhixiao.TableObject(SPECIAL_TABLE_ID);
break;
}
return table;
}

这样一来,只要在页面中引入相关的 api 方法就可以调用了:

1
2
3
4
5
6
7
8
9
import { getSpecials } from "@/api";

export default {
mounted() {
getSpecials().then(res => {
// Handle res.data.objects
});
}
};

因为知晓在 2.x 的新版本中增加了与平台无关的用户登录注册模块,所以在权限上有“匿名用户”与“登录用户”的区别。在使用 Web SDK 的时候,需要在相关应用的设置页中间打开数据表匿名读写的开关知晓云 - 设置

之前的数据表虽然新设置了 ACL 为“匿名用户可读,登录用户可写”的权限,但是旧数据行的 ACL 权限并没有根据数据表的 ACL 变化而变化,仍需要自己进行调整。可能是官方出于安全性的考虑吧,就我这种情况的话还是会觉得:“既然整张表格已经调整了权限,而且新录入的数据权限情况也是跟表格保持一致的,那么旧数据也应该自动更新”。这点我保持意见。(因为当时以为调完表的 ACL 后以为就都 OK 了的,调了半天还是返回 401,一开始还以为是 init 方式不对,折腾了大半天还是不行,已经冒出“我特么都自己架 API 了,用的好好的为啥还要搞这个”的念头,然后发了个工单,收起了想砸电脑的手。)

还有一点是,如果之前在小程序中已经是用过知晓的朋友应该知道,插件版的(因为我用的是插件版的,小程序 SDK 版的不清楚,不过应该都一样)知晓在每个请求的时候都会在控制台打印一句 Log。这个行为在小程序中我觉得没问题,毕竟普通用户在使用小程序的过程中是没办法开启调试的,所以有没有 Log 无所谓。但是在 Web 端不一样的是,控制台是可以被随时开启的。有太多的 Log 会导致开发者无法更合理地使用控制台,例如自己 console.log 的内容被一大堆 Log 推到最上面(当然只是我猜测的极端行为)。Log 在开发过程中是可以给调试带来便利,但是并不适用于生产环境中,所以我给的方案是,按 dev 下显示,在 prod 下隐藏。而且现在初始插件的 init 方法也可以带 options 了,虽然现在只提供了一个 autoLogin,我觉得可以再增加一个参数作为是否打印 Log 的控制:

1
2
3
4
import zhixiao from "minapp-sdk";
zhixiao.init("clientId", {
printLog: process.env.NODE_ENV === "production"
});

这次的 SDK 中发现了一个安全性问题,不过他们已经解决了就不提了。

最后还有一个,其实并不是问题,只是因为第一次碰到觉得挺有意思就在这儿记下来。上面提到的工单中我问了一个问题,我发现在控制台中可以看到,每次获取数据都会发起两个请求,一个 method=OPTIONS,一个 method=GET。第一个请求没有返回数据,但是返回了一串 method 的字符串:

1
GET,POST,PUT,DELETE

第二个请求才有返回我需要的数据。一开始以为是 bug 在工单里问了,客服的回答是:“这个是正常的,你可以查看这里:https://blog.csdn.net/cc1314_/article/details/78272329”。受益匪浅。【等等,那这个请求是算套餐内的请求吗 Σ(っ °Д °;)っ

目前使用的还都是数据的获取,等做到用户注册登录、提交和更新数据的时候再来看看有没有什么新的坑吧。

最后,再安利一波知晓云。【身为一名专业知吹

因为他们一开始的定位是微信小程序开发的 Serverless,所以从开发新版『戏词』开始就先选择了它试试。虽然戏词是一个 Side project,前后花在搭建上面的时间也只用了不到一礼拜的时间。在我熟练之后,曾花了一个周末(2 天)用他们搭建了一个类微博的小程序,可以实现微博的发送、评论、点赞、数据统计用户角色与权限(这个项目之后再考虑放出来),操作体验十分流畅便捷。这归功于他们专业的后台设计和稳定的服务质量,而且还有这太良心的定价(便宜到哭泣),是『戏词』能做到今天的关键。

如果你也有小程序想要快速上线,又苦于自己得购买域名服务器、申请备案、配置服务器数据库……那么可以找我点击这里注册,可以获取90元的体验券。3 天就能上线的小程序何苦要等上 3 个月呢?【一天 3 毛的话可以用快一年了都(嘻嘻

以上。