将一个纯本地应用移植到 Web 端

作者 | James Long

译者 | 王强

策划 | 李俊辰

如果小明有一个全部数据都存储在本地的应用，而这部设备被他失手扔进了大海，然后数据也一并烟消云散了。为了避免这种情况发生，我们可以尝试将一个纯本地应用移植到 Web 端。

在研究一个奇怪的缓存错误（）时我得到了启发，于是去重新看了一下 Actual 是如何在 Web 端本地存储数据的。这里我需要解释一些历史背景：多年前，Actual 原本是一个单纯的桌面应用程序来着。这意味着我们的所有数据都会存储在本地，没有服务器，自然也不会在网络上存储任何内容。

然后我意识到了移动平台的重要性，并且发觉大多数用户不想为这样的事情而担惊受怕：某天设备失手扔进了大海，然后数据也一并烟消云散。正因如此，同步引擎诞生了。从那时起，桌面和移动应用程序就可以愉快地同步它们的数据了。一份数据副本被保存在服务器上，这样用户就可以在登录后轻松查看他们的数据。如果担心隐私安全问题网页保存到本地，应用程序可以启用端到端加密。

去年，我开始嫉妒 Web 应用。看看那些应用吧，部署起来那么轻松方便……它们可以那么直截了当地将用户带入应用，用不着麻烦的安装过程。可是在桌面端，我得先要求用户下载 80MB 大小的文件，然后他们才能开始运行应用。这种下载需求当然会严重影响用户转化率，还会让登录流程、支持、A/B 测试以及所有事务做起来都麻烦许多。

我很喜欢桌面应用，因为你可以在桌面端用上好得多的技术（例如原生的 sqlite3）；桌面应用的速度也非常快（无需网络调用），并且用户可以完全掌控自己的数据。但我也不得不承认，Web 带来的种种优势让桌面端的这些好处相形见绌。

我开始考虑开发 Actual 的 Web 版本。经过一番研究，做了点技术活儿后，我没有改动整个架构就移植到了 Web 端。

这意味着你的所有数据仍会存储在浏览器本地，并且没有网络调用。它是在浏览器 [注 0] 中运行的完全 100％的“本地”应用。

我还没有对这个 Web 版本大肆宣传，因为它还没有经过足够的测试，并且有不少内容需要改进，例如采用代码延迟加载技术来加快加载速度。我最担心的是数据存储层。由于 所有数据都在本地存储，因此如果本地环境出现了什么问题，用户就可能会丢失数据。而且因为我们要把所有内容都存储在本地，这给浏览器的持久数据库也带来了巨大压力。

需要明确的是：我们不会弃用桌面版本。但将来，Web 版本将成为 Actual 的主要平台，如果用户需要则可以选择下载桌面版本。

它的工作机制不太常见。下面我从高级层面做一概述：

其实，这种方法和预写日志的工作机制很像。

我之前比较担心 IndexedDB 的可靠性。从它的文档来看，似乎浏览器可能会根据需要删除数据库，但实际操作中这种情况似乎没有发生 [注 1]。在存储空间不足的移动设备上这个问题可能会更突出，但我并没有趟移动 Web 这潭浑水（而是用了原生应用）。我还担心应用会到达 IDB 存储的上限，但正如接下来所解释的那样，这并不是个问题。

这项技术起初只是一项实验，但它的效果很惊艳。我在自己的 Actual 应用里有积累 5 年的数据，而它们在 sqlite3 db 中的大小是 9.7MB。消息表的阈值约为 50KB，因此对于一位已经使用 Actual 长达 5 年的用户，我也不过是在 IndexedDB 中存储总共约 10MB 的数据而已。这离 IndexedDB 的最大存储限制还差得远，目前它的上限至少为 500MB 之多。

到目前为止这个办法效果还不错，但是我希望对它建立 100％的信心。我一直在深入研究各种浏览器是如何在磁盘上存储 IndexedDB 数据的，并发现了我可以做出的一些改进策略。我本想在这篇文章中详细介绍一番，但最后我还是把主题放在了整体概述上。在下一篇文章中，我将深入研究 IndexedDB 是如何在浏览器中工作的。

注释

[0] 虽然我在这篇文章中没有谈论这个话题，不过它意味着整个应用都在浏览器中运行。“后端”运行在一个后台 Worker 线程中，并且一切都是在本地运行的。

[1] 如果本地数据真的被用某种方式破坏或删除掉了，那也不是什么大问题。所有更改仍将发送并存储在服务器上（这也是其他设备同步的方式）。如果出现问题，应用可以从服务器重新下载用户的所有数据。唯一会丢失数据的情况是用户在离线状态下丢掉了本地数据网页保存到本地，这也是理所当然的。