Zero-Rent Architecture：为 Swartland 农民设计
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you requested.
背景
这块田位于 Swartland 深处，距开普敦两小时车程。气温为 34 °C，空气中弥漫着麦秆和尘土，最近的基站被一座巨大的花岗岩山挡住。
此时站着一位刚收割了 40 吨小麦 的农民。他需要 现在 记录产量、位置和水分水平，随后才能转到下一个地块。
如果我给他一个标准的“硅谷”应用——前端沉重，从位于弗吉尼亚北部的 REST API 获取数据，通过 Auth0 进行身份验证——这个应用将毫无用处。它会卡顿、等待、超时，数据会丢失。更糟的是，农民会因为不信任而完全停止使用该工具。
对旧金山的开发者而言，“离线支持”是一个边缘案例——在进入地铁隧道时的可选功能。而对这位农民来说，离线是 唯一 重要的状态。
重新思考方法
这个认识迫使我重新思考我们如何为 “真实世界”——光纤城市之外的世界——构建软件。我不再问：
“我该如何 扩展 这套系统到一百万用户？”
而是开始问：
“我该如何让它对 单个用户不可破坏？”
答案不在云端。答案是 彻底删除云端。
第一道障碍：官僚主义
通过传统渠道把工具送到农民手中意味着：
- 将应用包装在原生壳中。
- 提交给 Apple 和 Google。
- 等待批准（或因轻微政策违规被拒）。
- 农民必须打开商店，搜索它，记起自己的 Apple ID 密码（三年前就忘了），并在受限的 3G 连接上下载一个 150 MB 的二进制文件。
这就是 臃肿。这就是 摩擦。
“Zero‑Rent” 解决方案
通过二维码分发
当农民回到办公室，连接着慢速但稳定的 Wi‑Fi 时：
- 他扫描 QR code。
- 相机打开浏览器，出现提示：“Add to Home Screen?”
- 他点击 Yes。
三秒钟后，应用被安装，出现在 WhatsApp 和 Gallery 旁边，看起来原生且感觉原生，但绕过了多美元的门槛行业。
离线优先架构
- 一旦图标出现在屏幕上，互联网连接就变成可选。
- 设备本身成为应用的整个宇宙。
持久本地存储：通过 OPFS 的 SQLite
标准的 Web 应用数据存储方式是 localStorage 或 IndexedDB。它们适合存放暗色模式偏好之类的轻量信息，但对于关键业务数据来说 简直是噩梦：
- 无结构。
- 大小受限。
- 浏览器随时可能将其清除。
为什么选择 SQLite（通过 OPFS）？
| 功能 | 好处 |
|---|---|
| 功能完整、符合 ACID | 与 Android、iOS 以及无数桌面应用使用的同一引擎。 |
| 快速 | 查询在毫秒级完成——无需网络往返。 |
| 关系型 | 复杂的 SQL（例如 “每公顷产量”）可在设备上直接运行，无需获取 JSON 并在 JavaScript 中过滤。 |
| 持久 | 数据保存在手机存储的受保护沙箱中；即使刷新、重启或进入飞行模式也能存活。 |
在这种架构下，手机不再是“客户端”。手机本身就是服务器。
创建发票 → 保存到 SQLite。
更新库存 → 保存到 SQLite。
没有加载指示器，没有网络延迟——只有瞬时交互。
Source: …
互联网的角色：备份，而非计算
手机很脆弱；它们会丢失、被盗或掉进泥巴里。如果设备掉进灌溉沟渠，数据也会随之消失。这就是我们需要互联网的唯一理由：用于保险，而不是用于计算。
通过 Google Drive 进行云备份
- 大多数用户已经拥有 Google 账户。
- 应用请求访问其 Drive 中的特定文件夹的权限。
- 当农民回到农舍的 Wi‑Fi 时：
- 应用检测到网络连接。
- 对 SQLite 数据库进行快照。
- 将该单个文件上传到他的 Google Drive。
结果：
- 隐私 – 开发者永远看不到数据；数据直接从手机传到 Drive。
- 成本 – 托管费用为 $0；农民也无需付费（使用免费层存储）。
- 弹性 – 换新手机 → 登录 → 拉取文件 → 从上次中断的地方继续。
我们实现了 “云备份”而不依赖 “云”。
预期的关注点与回答
| 关注点 | 回答 |
|---|---|
| 冲突 – 如果两个设备编辑同一条记录会怎样？ | 模型假设 单设备所有权。在此用例中并不需要冲突自由的编辑。 |
| 实时协作 – 多用户怎么办？ | 架构采用 离线优先；实时同步不在范围之内。 |
| 设备丢失 – 如果手机在同步前死机会怎样？ | 仍然使用互联网作为 快递：定期同步（例如在有 Wi‑Fi 时）可减轻数据丢失。 |
| 可扩展性 – 能否扩展到大量用户？ | 可以——每个用户在其 Drive 中拥有独立的 SQLite 文件。无需服务器端的扩展。 |
这些关注点常常源于一种偏见，即 每个软件都必须支持实时、多用户、冲突自由的编辑——这种信念会导致成本和复杂性上升。
摘要
- 离线是唯一重要的状态，适用于网络连接不佳的用户。
- 通过二维码分发 消除了应用商店的摩擦。
- 通过 OPFS 使用 SQLite 为设备提供可靠、关系型且持久的数据存储。
- Google Drive 充当廉价、保护隐私的备份“快递”。
- 其结果是 Zero‑Rent 架构：没有后端服务器、没有流出费用、没有复杂的认证流程——只有一个快速、可靠的工具，能够在最需要的地方运行。
应用是被动的；也是主动的。通过 Background Sync API 或简单的网络状态监听器，它会监控网络状态。一旦手机连接到 Wi‑Fi，同步就会在后台自动触发。
如果他在回到 Wi‑Fi 之前把手机掉进泥里怎么办？是的，那天的数据会丢失。但与那种因为没有信号而根本不保存数据的云优先应用相比，云端情形下数据根本没有产生。而在此情形下，数据至少还有一次生存的机会。
对工程师来说最难吞咽的药丸
并不是每个应用都需要多人协作。
听着，我知道这并不完美。如果农夫和他的妻子在同一秒钟尝试编辑完全相同的记录，其中一个人会丢失数据。要解决这个问题，你需要服务器、WebSockets、CRDT（冲突自由复制数据类型），以及——最重要的——每月的费用来支撑这种复杂性。
但看看使用场景。农夫在田里，妻子在办公室。他们不是在共同创作一本小说。他们只是在记录各自不相干的事件。对于 90 % 的小企业来说，“单用户”模式已经足够。
- 说**“不”**接受实时协作，我可以在一周内完成这个应用的开发，免费托管，并且它可以永久运行。
- 说**“是”**接受实时协作，我就签下了数月的开发时间和终身的维护。
对小麦农夫来说，他最需要的功能并不是**“实时协作”，而是“按下按钮就能正常工作”**。
为什么我们仍然关注硅谷的前景
我们痴迷于微服务、边缘计算和无服务器函数，因为这正是 Netflix 和 Uber 所做的。但在此过程中，我们常常忘记了真正为谁而构建。
- 我们并不是在为 Netflix 构建。
- 我们是在为 Swartland 的农民构建。
- 我们是在为 Soweto 的机械师构建。
- 我们是在为开咖啡店的开普敦老板构建——他们看着利润率在每月的 SaaS 费用和数据套餐中逐渐消失。
“Zero‑Rent” 架构
“Zero‑Rent” 架构并不仅仅是对糟糕基础设施的变通方案。它挑战了以下假设：软件必须租用，数据必须存放在数据中心，且当路由器的指示灯变红时应用就会停止工作。
通过押注 Local‑First、SQLite 和 User‑Owned Storage，我们将权力归还给网络的边缘：
- 速度 – 物理限制胜过光纤。
- 所有权 – 他们的数据，他们的驱动器。
- 弹性 – 它始终可用。
新的网络愿景
非洲常被视为需要“赶上”西方的市场。但在一个日益关注隐私、云成本和能源效率的世界里，我相信事实恰恰相反。
通过为农民解决问题，我们并不是在构建一个次等版的网络，而是在打造它的下一代——一个更轻、更快、更尊重使用者的网络。
最初发布于 nanosoft.co.za