我用 Google Drive 文件夹替换了应用的数据库

Translated for your language. 阅读原文.

AI-assisted draft.

我想记录女儿学习音乐的进度。她每周都会收到老师发来的音频片段和笔记。我想随着时间的推移听听她的练习过程。我不希望新的录音覆盖掉旧的录音。

为了解决这个问题，我开发了一个应用。它没有后端，没有数据库，而且成本为零。

大多数开发者都忽略了 Google Drive 的一个功能：修订历史记录 (revision history)。

当你上传一个具有相同名称和 ID 的文件新版本时，Drive 会保留旧版本。它会保留时间戳，并且可以进行浏览。

我没有构建包含表和外键的复杂数据库，而是简单地覆盖文件。Drive 会处理版本控制。我的应用只需调用两次 API 即可显示历史记录。我没有编写任何版本控制逻辑。

文件夹结构充当了我的数据库模式 (schema)：

• 每首歌都有自己的文件夹。 • 文件使用类似 teacher-audio 或 student-practice 的前缀。 • 我不使用 JSON 来描述结构。 • 添加新文件夹会自动更新应用。

我还需要一种标记歌曲的方法。我没有为此使用 JSON 文件，而是使用了 Drive 的元数据属性 (metadata properties)。你可以直接向文件夹添加键值对 (key-value pairs)。这样可以将所有操作合并在一次 API 调用中。

配置如下：

• 托管：GitHub Pages (免费) • 认证：Google Identity Services (仅限客户端) • 存储：Google Drive • 数据库：无。文件夹结构即模型。 • 总成本：$0。

一个提示：Drive 会在 30 天后清除旧的修订版本。你必须设置 keepRevisionForever 标志来保存它们。

这不是一个面向公众的产品，而是我为家人准备的个人工具。

我的目标不仅仅是省钱。我的目标是确保两年后，我只需点一下按钮，就能听到女儿今天的练习声音。这种架构让这一切在无需额外维护的情况下成为可能。

你是否曾将 Drive 的修订历史记录或属性字段用于基础设施构建？

继续阅读