第一次做小程序云开发,昨晚第一次需要切换后台环境,发现如果要切换环境的话,需要逐个云函数修改它的
|
方法,在里面加入要切换的环境的环境id,并且切换之后需要逐个云函数部署到云后台去——这着实让人难受。
于是准备进行云函数归一的工作,即,将所有云函数写在同一个云函数内,实现 “如果需要切换环境,只需要修改一个文件,部署一个云函数即可” 的效果。经过一些摸索,卓有成效,下面将一些经验分享给大家。
首先,我希望达到的目标是:
实现归一化:让所有云函数功能都写在一个云函数中。
易接入:
不要对现有的云函数有太大的改动。一些云函数比较复杂,改动太大容易出bug。
小程序端的接入方式也不要有太大的改动,不然也容易出问题。
可维护:尽量避免由于实现归一化,而增加不同云函数间的耦合,尽可能和原有的云函数机制一样,不同的云函数各自隔离。
好扩展:以后再新增云函数,不要修改太多地方。最好像现有云函数一样,右键新建,然后就可以开始写功能了。
为了实现以上目标,我采用了如下方案:
1. 云后台端:
a. 新建一个router云函数,在其内新建一个function文件夹,将其他所有云函数的 index.js 的名称改为云函数的名字,并放入function文件夹。进行这一步之后,router云函数的目录结构为:
└─router │ index.js(“router”云函数的index文件) │ newFuncTemplate.js │ package.json │ └─functions onClick.js(原“onClick”云函数的index文件) publish.js(原“publish”云函数的index文件) |
// 云函数入口文件 const cloud = require( 'wx-server-sdk' ); cloud.init(); // 云函数入口函数 exports.main = async (event, context) => { log(event , "收到云函数调用" ); const funcMain = require( "./functions/" + event.funcName + ".js" ); // 根据funcName寻址云函数 return await funcMain(event, context , cloud); // 将任务分发下发。此处要将 cloud 传下去 }; |
c. 修改 function 文件里面的所有云函数文件,主要由两个修改点:
c1. 需要使用构造函数里面传进来的cloud。
c2. 需要将入口函数暴露出去。
修改结束之后的各个云函数文件如下所示:
2. 小程序端
小程序端需将所有请求的 name 都改为 router,并且在传的 data 里面加上 funcName 参数,其值为之前原本要调的云函数方法名。
// 修改前 wx.cloud.callFunction({ name: "deleteMyPublish" , data: { id: key }, success: res => {} }) // 修改后 wx.cloud.callFunction({ name: 'router' , data: { funcName: "deleteMyPublish" , id: key }, success: res => {} }) |
3. 后续新增云函数
后续新增的话,就直接在 function 文件夹里面新建一个以云函数命名的 js 文件,然后把上面 1.c 里面的代码复制进去,就可以直接写逻辑了。
大概就是这样了。这个编辑器真的很难用,什么时候能支持 Markdown ?
我也做了类似的结构,这个问题的根源还是在于云函数的环境无法自动切换,不管你部署到哪个环境,都要手动指定 env,如果能自动读取部署环境就没这个问题了,还有就是类似全局工具的,现在的云函数是函数间隔离的,这就导致一些工具类无法共用,种种原因吧
仁者见仁吧,这种模式so far未见有什么好处。
主要好处有两点: 1,不用一个一个部署云函数
2,切换环境可以一键切换
你改一个标点符号都得重新部署一次,以前是改函数A部署一次A,改函数B部署一次B,现在是改A部署一次router,改B也部署一次router。如果A的npm依赖和B的依赖不相同,你还得每次都安装所有依赖。
明明是更复杂,更不合理了。
赞同楼上各位, 意义不是特别大。
调用次数没有节省, 就是云函数个数节省了。
可以自动读取当前部署的环境就好了!
有点意思,这样的话云函数调用次数就节省很多了
/个性签名,不服不行
呵呵,次数一点也没少吧。无非是:
调用A=调用router(A):都是一次
调用B=调用router(B):还是都算一次。
这段代码贴在正文里死活无法发布成功,迫于无奈,在这里贴一下。