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

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

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

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

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

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

原文链接：https://forum.laf.run/d/984

技术选型过程

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

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

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

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

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

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

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

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