业界首个直观可视化全栈应用架构和数据流的框架,399次互动反映强刚需;对调试复杂应用和架构理解帮助巨大。
想象一下,你正在开发一个全栈应用,并准备实现一项新功能。这个功能相当复杂,于是你拿出纸笔,或者打开 tldraw,开始绘制应用当前的架构图:从数据库到服务器,再一路延伸到客户端。
但如果有一款工具,能直接把你的整个全栈应用可视化出来,是不是很酷?如果它还能做更多事情呢?比如立即为整个技术栈添加实用功能,或者与 AI 和 Large Language Models 配合完成代码生成。
其实,这个想法已经成为现实,它就是 wasp studio。
首先,Wasp 是一个拥有超能力的全栈 React、NodeJS 和 Prisma 框架。它在 GitHub 上的 star 数刚刚突破 10,000,并且已经被用于创建超过 50,000 个项目。
它有什么特别之处?Wasp 使用一个配置文件和自己的编译器,替你管理身份认证、cron jobs、路由和邮件发送等大量功能,帮你节省许多时间,让你可以专注于真正有趣的事情。
Wasp 的中央配置文件相当于一组应用指令。它与编译器结合之后,还能通过单行命令替你完成许多复杂而有趣的任务,例如:
全栈部署 → wasp deploy
使用 Docker 启动开发数据库 → wasp start db
搭建完整的示例应用,例如 SaaS starter → wasp new
生成整个全栈应用的可视化结构图 → wasp studio
如果你想亲自试试,只需要:
使用 npm i -g @wasp.sh/wasp-cli 安装 Wasp
使用 wasp new -t todo-ts 搭建一个采用 TypeScript 的全新 To Do 应用
然后运行 wasp studio,即可得到下方截图所示的可视化界面
我们来快速拆解一下这里看到的内容:
中间蓝色的主 App 组件展示了应用名称、正在使用的数据库以及 Auth 方法
左侧黄色的 Entities 展示了我们定义的数据库模型
最左侧红色和绿色的 Actions 与 Queries 展示了会操作数据库实体的服务器端操作
右侧的 Routes 和 Pages 展示了 React 组件所在的位置,以及它们是否需要授权——需要授权的页面会以 🔒 标记
如果你想知道更复杂的应用会是什么样子,下面展示的是 Wasp Studio 针对 Open SaaS 运行后的效果。Open SaaS 是我们免费、开源的 SaaS boilerplate starter。
它的一大优点是,我们可以纵览所有数据库实体,以及哪些服务器函数——也就是“operations”——依赖这些实体。在上图左上角,你甚至可以看到一个名为 dailyStatsJob 的 cron job,它每小时运行一次(0 * * * *)。
举例来说,这会让后端逻辑的开发变得轻而易举,尤其适合经验不太丰富的后端开发者。实现这一效果所需的代码就是这么简单:
job dailyStatsJob { executor: PgBoss, perform: { fn: import { calculateDailyStats } from "@src/calculateDailyStats" }, schedule: { cron: "0 * * * *" }, entities: [User, DailyStats, Logs, PageViewSource]}
没错,只需要这些代码,你就能在服务器上运行异步任务。现在,calculateDailyStats 函数将每小时运行一次,而且不需要任何第三方服务 🙂
好吧,你可能会想:这个可视化工具确实很酷,但它真的有实际用途吗?还是说,它只是一个看起来不错的“炫技小把戏”?老实说,就目前而言,它确实只是个炫技小把戏。
但这个小把戏蕴藏着巨大的潜力。让我解释一下。
当然,你现在就可以用它更清楚地了解自己的应用,或者规划一些新功能。但未来,你将可以用它完成更多事情,例如:
点击几下即可添加新的 Auth 方法
快速搭建能够配合服务器端 operations 使用的客户端功能组件
立即为整个应用添加新的全栈功能,例如 Stripe 支付
轻松与 Large Language Models(LLMs)协作,实时生成功能!
这一切之所以能够实现,还是因为那个中央配置文件。它相当于应用的一组“指令”。有了这个文件,Wasp 真正了解你的应用是如何构建的,因此可以轻松地将应用以可视化形式呈现出来。它也让 Wasp 更容易用令人兴奋的新方式替你构建应用的新组成部分。
看看下面这个来自 Wasp 配置文件的代码片段。只需要这些代码,就能为你的 Web 应用实现全栈 Auth!这是因为 Wasp 编译器会替你管理那些 boilerplate 代码。
app todoVisualize { title: "todo-visualize", auth: { userEntity: User, methods: { usernameAndPassword: {}, google: {}, }, }}entity User {=psl id Int @id @default(autoincrement()) tasks Task[]psl=}
现在,我们已经对 Wasp 的工作方式有所了解,接下来进一步看看 Wasp 与 wasp studio 结合 LLMs 后,未来可能有哪些使用场景。
目前,AI 辅助代码生成面临的最大限制之一就是上下文。如今,我们都知道 LLMs 喜欢产生幻觉,而且它们的“记忆力”也相当糟糕。因此,如果你想让它们为应用构建功能,为了确保新功能能够正常融入现有应用,你就必须不断“提醒”它们应用的工作方式、结构和依赖关系。
但借助 Wasp 的配置文件——它本质上就是对全栈应用及其功能的一种高层抽象——我们可以向 LLM 提供成功为当前应用构建新功能所需的上下文。
这种方式非常有效,因为我们不仅向 LLM 提供了它需要的上下文,而且 Wasp 编译器从一开始就承担了编写大部分 boilerplate 的责任(谢了,伙计),让 LLM 只需完成一些更简单的任务,例如:
修改 Wasp 配置文件
编写将在服务器上运行的函数
编写使用 Wasp 代码的 React 组件
这样一来,LLM 需要保留在上下文中的内容就少得多,我们也可以原谅它糟糕的记忆力,因为负责确保一切紧密衔接的那个角色是 Wasp!
为了进一步说明这一点,让我们再次看看前面介绍过的 Auth 代码:
auth: { userEntity: User, methods: { usernameAndPassword: {}, google: {}, },
请注意,这段代码会为你的整个技术栈提供 Auth。你不仅可以在服务器端获得自动生成并由 Wasp 管理的全部 Auth 逻辑,甚至还能在客户端直接使用 UI 组件和 Auth hooks!
反过来说,如果没有 Wasp 提供的抽象,我们最终就只能依赖记忆力糟糕、又容易产生幻觉的 LLM,一遍又一遍地替我们编写大量 boilerplate,比如下图所示的 JWT middleware。
如果单独处理 boilerplate 式的重复任务,LLMs 的编码表现确实相当不错。但如果期待它们把这些任务作为一个结构严密的全栈应用的一部分来完成,就意味着可能出现错误的地方会多得多。
使用 Wasp 则只需要几行代码。既然人类写起来很容易,LLM 写起来当然也会非常容易。
顺便一提,这不仅能省去大量麻烦,还能替我们节省许多费用。AI 生成的 Wasp 应用所使用的 token——也就是输入和输出文本——比同类工具少约 10~40 倍,因此只需花费一小部分成本就能生成代码。
随着技术不断进步,编程将向缺少专业知识的用户变得更加开放,因为越来越多的专业知识会被嵌入我们的工具之中。
但这也意味着,我们需要合适的抽象,让身为人类的我们能够轻松地使用这些工具。
就像上面的 LLM 示例一样,我们可以构建工具,让 AI 一遍又一遍地替我们编写所有 boilerplate。但问题在于:既然它们可以完成其他更有价值的事情,我们真的应该让它们一直做这些工作吗?LLMs 非常擅长快速产生大量新想法。为什么不构建一些工具,让 AI 在这方面帮助我们呢?
这正是我们为 wasp studio 规划的未来:提供一个可视化界面,让你能够在有或没有 LLMs 帮助的情况下,将应用的新功能组合起来,然后快速对不同想法进行 A/B 测试。
不仅如此,我们还能获得一种便于和技术背景较弱的用户展开协作的抽象。借助这类工具,就连你的 Product Manager 也可以参与其中,开始构建新功能,再交给开发者审核确认。
Wasp 及其功能集真正强大的地方在于:无论对人还是机器来说,它都能让代码更易于阅读、调试和维护。再配合可视化界面,我们将能够在整个技术栈中快速迭代新功能。我们既可以亲自将它作为规划和编排工具使用,也可以借助它更轻松地调试和监督 LLM 为我们完成的工作。
这是对 Web 开发未来的一次振奋人心的展望。随着这些新工具的出现,我们还将发现许多使用它们的新方式。
你认为,像 wasp studio 这样的工具还能用在哪些地方?对于 AI × Human 协作领域即将出现的其他进展,你又有怎样的想象?