使用 Laf 一周内上线美术狮 AI 绘画小程序

“美术狮 AI 绘画”（以下简称“美术狮”），是我们小团队的一次尝试，定位是人人都可以上手的，充满创意的，理解中文和中国文化的图片生成工具。

在完善图像模型和论证核心问题之后，我们开始构建 MVP（最小化可行产品）。MVP 的构建需要：

实现快，开发周期较短
模式轻，产品重点突出
成本低，只投入较少的人力、物力

这些目标，对于我们而言都是不小的挑战。得益于 Laf 的使用，从开发到第一个版本上线，只用了一周时间；小程序功能精简、目标清晰；主体服务成本（杭州+新加坡）在 100 元 / 月以内（含有优化空间）。

下面会结合“美术狮”MVP 构建的全过程，和大家交流使用 Laf 这个平台（技术）的思考。

laf技术选型过程

函数即服务，是目前我们对 Laf 范式的思考和理解。也是“美术狮”选择 Laf 作为服务端的主要因素。

我在 2015 年就接触了“类似”的 BaaS 平台 LeanCloud，并做过两次实践。第一次是对爬取的小红书内容做维护，第二次是给一个中科院的朋友做化学试剂编号的管理。

LeanCloud，偏向于数据库即服务这种范式，对数据增删改查，提供基于数据的丰富的查询、聚合运算方法是这个范式的核心。

范式无优劣之分，取决于需要解决的问题场景、复杂度和规模。对于以数据库为中心的，包含简单鉴权的系统比如 CRM、甚至是 ERP，LeanCloud 都可以很好地适应和匹配。

我们还尝试和了解过主打实时性的野狗云（已下线），以及后来上线一段时间又被字节跳动下线的轻服务（已下线）。也尝试过跟着教程使用 Firebase。

“美术狮”或者其他的 AI 应用的实际使用场景中，数据库的操作只是一个部分，复杂的内容生成逻辑、多平台资源调度、相对密集的计算是这类场景中的重心。

小程序本身，虽然运行在客户端内拥有一定的计算能力，但是把它看作一个增强的 BS 结构通用性会更好，我们需要把大量地生成逻辑和计算处理流程剥离出来放在服务端由多平台协同完成；同时为了减小分发包的大小，当需要包含其他 SDK 文件时，我们也会格外谨慎。

因此，数据库即服务，并不能很好地解决我们所面临的问题，可能并不是 AICG 应用优先会选择的范式。

腾讯云函数（Serverless）

接下来尝试了使用腾讯云函数，能满足了我们的一部分需求。

但是对于单次计算相对密集，调用资源繁多，访问量不稳定的应用而言。冷启动是可怕的，服务被冷却后，再一次被拉起来需要较长地等待时间。在并发和访问量不大时，云函数被频繁地冷却，对用户体验伤害较大，较为致命。这个对于每一个从 0 到 1 的独立开发者可能都是个头疼的问题。

对存储桶、数据库，腾讯云函数并没有做深度地整合，单独配置云数据库、存储桶，会在 MVP 阶段增加不必要的时间和费用的开销。

微信云开发

微信云开发可以通过微信开发者工具一键开通。在“美术狮”迁移的 Laf 之前，我们在微信云开发中做了大量的尝试。

放弃使用微信云开发，主要是下面一些原因：

基础库 Node 版本过低，对第三方包支持不好；
IDE 开发体验不好，写代码像是看 PPT，本地调试不够方便直观；
计费系统诡异，虽然我们是腾讯云的老用户，小程序无法在原有账户中开通服务，必须以小程序的维度新开通账户，付费和管理维护不方便；
对跨区域、跨服务支持不佳；
冷启动延迟依然明显。

通过内置的鉴权机制快速获取 openid，是微信云开发宣称的优势。

在“美术狮”产品迁移后到 Laf 后，结合社区教程，也可以在“3 分钟”内，实现实现这些功能。

从 0 写一个微信小程序对接 Laf 云开发获取用户 openid

Supabase、Vercel、Cloudflare

Verce、Cloudflare 是我特别喜欢的两个平台，这里一笔带过。主要原因是无法整合到国内的网络环境中。

最终我们选择了 Laf。在使用 Laf 的过程中，我们获得几乎等同于 Woker、EdgeFunction 的使用体验和开发效率。

为什么选择 Laf？

函数即服务

Laf 最吸引我们的，是通过云函数的构建应用的方式。

函数即服务在一定程度上，是可以包容（包含）数据库即服务这个范式的。

传统的 Server 端开发，通过 Router 和 Controller 去组织代码，利于管理和维护。但是，从另一个层面看，会在一定程度上，降低了 MVP 产品的开发效率，阻碍了创新的落地。

“美术狮”在第一个版本上线前半个小时，决定添加一个每日签到的功能。

通过云函数，我们更聚焦新特性、新功能，而不是困在这个签到功能应该放在哪个 Router 下，哪个 Controller 下这些工程管理的思考中。通过定义一个 task_user_daily_check_in，我们很快地实现了这个功能。

云函数调用云函数，是另外一个我喜欢的特性，我们定义了若干个“内部”云函数（同时关闭了所有 HTTP 方法），来为其他云函数服务。比如获取第三方服务的 access token 并在本地持久化。一方面，代码能够解耦和复用，另一方，安全性也大大提升。

例如这段代码，获取百度云服务的 access token ，关闭请求方法后，仅能被内部调用。

import cloud from '@lafjs/cloud'

export default async function (ctx: FunctionContext) {
  const ret = await cloud.fetch({
    url: "https://aip.baidubce.com//oauth/2.0/token?",
    method: "get",
    params: {
      'grant_type': 'client_credentials',
      'client_id': process.env.BAE_CLIENT_ID,
      'client_secret': process.env.BAE_CLIENT_SECRET
    },
  });
  cloud.shared.set('bae_access_tooen', ret.data.access_token)
}

当然，云函数过多后，仅能通过修改函数名去人为地调整云函数的排序，目录结构会显得凌乱，如果能按照 Tag（虚拟文件夹）去聚合、管理云函数，对我而言，会更清晰和直观。

技术栈友好

Laf 使用 Typescript（ Javascript ）进行开发，与 web 端、小程序开发属于同一技术栈。大大降低了全栈开发的难度，同时绝大多数代码可以在两端进行复用。

在避免讨论“谁是世界上最好的编程语言”的前提下，仅从团队、成本、开发效率几个方面讨论，一致的技术栈是 MVP 开发的一个好选择。

良好地第三方支持

Laf 对第三方 NPM 包的支持很好。我尝试过引用 moment 等这些第三方库处理时间数据，七牛等第三方服务处理图片资源，同时内置了大量常用的第三方库。

如同乐高拼图，云函数可以不断地、从不同维度地整合和丰富。存在大量第三方依赖的项目，迁移时成本较低。

实测，秒下各类第三方 NPM 包，精准版本控制，不需要“魔法”。

开箱即用的数据库

Laf 内置了对 Mongodb 的良好支持，提供了一个开箱即用的数据库。够用，好用。

Laf 除了提供大量封装后的查询、聚合方法外，也提供了与原生 Mongo 交互的接口。

例如：通过与原生数据库交互创建索引。

import cloud from "@lafjs/cloud";
const db = cloud.database()

export async function main(ctx: FunctionContext) {
  let res = await cloud.mongo.db.collection('users').createIndex({ "openid": 1})
  const resIndexs = await cloud.mongo.db.collection("users").indexes()
  return resIndexs
};