个人应用：JavaScript 与 SQLite 就够了

挑战

AI 正在改变专业软件的构建方式，而我们的行业仍在摸索这意味着什么。但我认为更大的转变在别处：不在专业开发中，也不在试图遵循当今软件开发模式的 vibe-coded 应用里，而在我称之为个人应用的新类别中：围绕一个人需求构建的软件。它们可能支持一项爱好、简化一项日常任务，或解决一个工作问题。

当任何人都能构建软件时会发生什么？他们如何构建自己的软件？他们需要哪些防护措施？我们如何在不危及其它应用或其数据的情况下运行每个应用？数据存放在哪里？我们如何可能运行成百上千个这样的应用，以及如何为可能长期价值不大的应用控制基础设施成本？

JavaScript 和 SQLite 就够了

对于个人应用来说，当今的软件技术栈过于繁重。是的，你需要数据库，但当你只是想从朋友那里收集信息时，你需要一个带分布式事务的全球数据库吗？是的，你需要运行你的逻辑，但当你只是想做些计算并更新一个工作仪表板时，你真的需要一个完整的 Linux 环境吗？

在过去几个月里，我一直在测试仅用 JavaScript/TypeScript 和作为本地数据库的 SQLite 能走多远。答案是：出乎意料地远。以下是三个例子：

示例

Bonn Tonne

Bonn Tonne（https://bonn-tonne.applet.works/）（源代码（https://github.com/applet-one/examples/tree/main/bonn-tonne））将波恩官方的垃圾收集日期转化为针对你的地址和垃圾桶的个人日程，你还可以在日历中订阅它。它不需要用户账户：偏好设置保存在浏览器的 localStorage 中，而日历订阅则存储在 SQLite 中，位于一个不可猜测的 feed URL 之后。

Daybreak

Daybreak（https://cobaltsparkling-puma.applet.works/）（源代码（https://github.com/applet-one/examples/tree/main/daybreak））帮助朋友分享空闲时间、找到重叠的空闲时间并安排会议；接受请求会为双方保留该时间。与 Bonn Tonne 不同，它自行实现用户认证：注册、登录和登出，使用加盐密码哈希和基于 cookie 的会话，其令牌以哈希形式存储在 SQLite 中。用户、会话、好友关系和日程都存放在一个由 SQLite 支持的 Durable Object 中，无需单独的身份服务。

Quote-Assist

Quote-Assist 是一个内部原型，用于帮助销售代表将客户询价转化为报价，汇集相关信息并突出仍需澄清的内容。销售代表始终掌控决策和客户沟通。它展示了一个个人应用如何在现有业务软件之外支持一个专注的工作流程。

作为一个爱折腾的人，我喜欢能随手使用 TypeScript 这样的完整语言，以及通过 SQLite 使用熟悉的数据库接口。我是在这两种技术中成长起来的，用它们相当高效。现在，事实证明这不仅对我如此，对许多其他人也是如此。但更重要的是，当前一代 LLM 非常擅长它们。它们已在数百万行 TypeScript 上训练过，也见过足够多的 SQLite。经过少量来回交流，它们生成了所有示例。如果你提供正确的防护措施和上下文，你通常可以一次成功。这很惊人，我相信这可能成为许多许多其他应用的最佳平衡点。

但拥有简单的应用模型只是故事的一半。我们究竟如何实际运行这些应用？我们是否需要构建全新的基础设施来支持它们？幸运的是，大部分基础设施已经存在，无论是在云端还是在我们自己的服务器上。

Durable Objects

一些读者会认出这个技术栈。另一些人则已经用这种模型摸索了一段时间。Cloudflare 的 Durable Objects 是最突出的例子。

Cloudflare 于 2020 年推出 Durable Objects，为其 JavaScript Workers 提供持久化存储。它们的实现非常出色，值得深入探讨，但它给了我所需的东西：一种在其 V8 运行时上运行 JavaScript 或 TypeScript 并将数据存储在 SQLite 中的方式，并由其对象存储 R2 提供支持。它们还让我认识到一个新的约束：对数据库的单线程访问。到目前为止，我对这个约束相当满意，我相信这个约束将带来更简单的运维模型。

但真正让 Durable Objects 背后的理念变得有趣的是 Ryan Dahl（Node.js 的创造者）的一个名为 celld（https://celld.dev/）的项目。本质上，它是 Durable Objects 的开源实现，使用了部分相同的底层技术，如 V8 和对象存储，但完全运行在你自己的基础设施上。同样，这是另一个深入探讨的话题。但我们现在已经具备了在自己的服务器上运行这些应用的基础条件，这是许多组织甚至考虑采用它们的硬性前提。

如果你想试用 celld，可以看看 celld-ctl（https://github.com/applet-one/celld-ctl），它提供了一个单服务器控制平面，让你能在 15 分钟内开始在服务器上构建我们谈到的这些个人应用。

为什么这适用于个人应用

好了，所以有前景的部分在于这种组合：一个 LLM 可以处理的简单应用模型，以及运行它的现有基础设施——在云端用 Durable Objects，或在我们自己的服务器上用 celld。这还不是一个完整的个人应用平台，但它意味着我们不必从零开始构建运行时和存储基础设施。所以回到最初的问题：这种组合能否成为构建这些个人一次性应用的基础？

首先，它们很容易生成，因为 LLM 非常了解 JavaScript 或 TypeScript 以及 SQLite。你会惊讶于当今的模型能带你走多远。

它们默认是隔离的：每个应用运行在自己的 V8 隔离环境中，拥有自己的 SQLite 数据库，因此有缺陷或恶意的应用无法触及另一个应用的代码或数据。它们易于运维，因为逻辑和状态被封装在一起。它们易于扩展：每个实例都是独立的，更重要的是，当无人使用时可以缩容到零。说实话，对于我们许多一次性应用来说，这将是常态。此外，Cloudflare 非常慷慨的套餐让你基本上可以免费运行许多这样的应用。

而且它们足够强大。我的假设是，这可以覆盖大约 90% 的个人应用，无论是私人使用还是工作中使用。

这种模型在哪里触及极限

那么这个模型在哪里不足呢？首先，不同应用之间的交叉通信并非内置功能。我怀疑许多企业架构师会提出需要跨多个应用进行某种分布式事务的用例。此外，你可能会认为你的应用可能无法整齐地适配到一个小的、隔离的运行时中。而我认为，当你想构建和运营许多这类应用时，这些约束恰恰是一种特性。

所以我想更大的问题是，当我们从少数几个个人应用扩展到成百上千个时，会出现哪些挑战？我们如何知道什么在运行？谁对这些应用负责？我们如何确保它们遵循组织标准，同时又不失去最初让它们具有吸引力的简单性和自由度？

这些是我们正在积极探索的问题，我很想听听你的想法、问题和顾虑。你认为这个模型在哪些地方行得通，在哪些地方会失效？

更多内容即将推出

最后：我将在纽约 AI DevCon（https://tessl.io/devcon）的 upcoming 演讲中讨论这个模型及后续挑战：Software Factories for the Software of One（https://tessl.io/speaker/matthias-luebken）。希望在那里见到你！