无服务云函数作为云计算的服务类型

云函数给用户带来的价值主要4点：

1. 简化架构：函数粒度的微服务架构，使得系统的各个功能天然解耦，能像搭积木一样组合自有及外部服务，实现所看即所得的后台服务；

2. 简化开发：无需关注底层硬件配置、OS，服务启停、网络收发，故障容灾，服务扩缩容等，只需写最核心的业务逻辑，实现真正的代码即服务；

3. 简化运维：无须关注服务部署，服务器运维，安全管控，扩缩容配置等，且应用能无缝升级，实现无痛切换到DevOps模式。

4. 减少支出：无闲置成本，仅对函数资源大小，执行时间，执行次数按需计费，相对云主机平均5%~15% 的使用率，价格优势明显，实现了最彻底的按需计费。

Flow.js在基本语法上和TS很相像，我认为它是一个针对老项目的类型推导方案，因为只需要安装简单的包和给文件加入Flow的标识就可以给对应的文件提供类型推导的功能，所以针对目前我所做的这个业务来讲，不存在老项目，所以既然是新项目就不如直接上TS。

在云函数开发过程中，我们在插件市场选择了一款非常简洁已拓展的explain框架，这个框架目前已经支持单路由和restfulAPI还有基本的过滤拦截器，那么目前这个框架没有做TS的解决方案，我就斗胆替作者大大想一个曲线救国的方案，而且这个方案有以下特点：

uni官方的云函数大小限制是10M，所以我们不能把依赖都安装在项目中，需要我们全局安装：

2个插件的玩法很多，尤其是nodemon，在我们这个解决方案中我们只需要简单的配置几个文件就可以把我们的项目跑起来了。

我们的云函数目录是这样的，这是搭配了前面提到的explain.js，在etsc.config.js中我们可以配置一下，输出的js版本规范以及目录和是否进行压缩：

在services目录中编写完ts文件之后，esbuild-node-tsc会把js文件放到dist目录之下，我们现在只需要更改explain.js默认配置：

这样explain会从dist下找文件而不是从services文件下找

我们在这个根目录下运行编译命令即可

这个时候我们运行这个函数就会发现，它已经达到了我们的目标了：

但是我们需要services下的文件一变更就编译放到dist下，我们就需要nodemon帮助我们做这个事情（nodemon.json）：

监听services目录，包括文件名为ts,js,json，执行命令etsc

然后我们再把这个运行nodemon的命令放到package.json中：

---