构建‘Backend-less’博客站点：我与 Coffee Chronicle 的旅程

Source: Dev.to

coffeechronicle.aniruddhagawali.dev

想法：为什么要 “无后端”？

Coffee Chronicle 的灵感来源于想看看现代数据库能够处理多少业务逻辑。传统上，数据库只是被动的存储层，而后端负责认证、校验和业务逻辑。我想把这个剧本翻转一下。

注意： 该架构是一个实验性的学习项目。它演示了数据库驱动的开发，但并不一定适用于需要专门后端服务提供更好可观测性和中间件灵活性的 大规模生产环境。

为什么选择 PostgreSQL？

选择 PostgreSQL 不仅因为其可靠性，还因为它的可编程环境：

• PL/pgSQL – 直接在数据库中编写复杂的过程逻辑。
• 原生 JSON 支持 – 适合来自富文本编辑器的动态内容。
• 扩展生态系统 – 添加加密、专用数据类型等功能。

前端直接连接数据库

在 Coffee Chronicle 中，“后端”由 PostgreSQL 内的 存储过程和函数 组成。Next.js 前端通过 Server Actions 调用它们。

不再在应用代码中嵌入 SELECT 或 INSERT 语句，而是让前端调用函数，例如：

SELECT create_blog(...);

这样可以将模式逻辑封装在数据库内部，消除 API 端点与查询之间的大部分胶水代码。

在数据库内部进行认证

所有认证流程都在 PostgreSQL 内部处理，无需外部提供商：

• 用户注册 – 存储过程插入凭证。
• JWT 管理 – PostgreSQL 扩展生成并验证 JSON Web Token。登录时，数据库验证凭证并返回签名令牌。
• 会话完整性 – 仅接受有效且未过期的令牌来进行数据修改操作。

通过行级安全（RLS）实现安全

没有传统后端时，安全性通过 RLS（行级安全）策略 在行级别强制执行：

• 公共访问 – 任何人都可以读取已发布的博客。
• 私有所有权 – 只有作者才能编辑或删除自己的帖子，使用类似 USING (auth.uid() = author_id) 的策略强制。
• 隔离 – 用户即使知道博客 ID，也无法访问其他用户的草稿内容。

挑战与经验教训

创建无后端应用带来了若干障碍：

• 安全性与调试 – 缺少传统的堆栈跟踪，需要严格的 SQL 错误处理和日志记录。
• JWT 密钥管理 – 确保密钥安全地供数据库用于签名。
• 输入校验 – 每个函数必须严格防止 SQL 注入并保持数据完整性，因为数据库是最终的守门人。

最后感想

构建 Coffee Chronicle 让我们看到 PostgreSQL 远不止是表格存储；它是一个复杂的运行时环境。虽然在复杂的生产系统中我可能会回归传统后端，但我对数据库的强大功能有了更深的认识。如果你想了解数据、安全和身份是如何交织在一起的，尝试 “删除你的后端”，让数据库来说话吧。