为什么要有另一个后端系统？

开发数字产品通常需要同时构建后端（业务逻辑）和前端（界面）。自己从零实现后端，尤其是身份认证和数据库管理，非常复杂且耗时。虽然后端框架能加速开发，但常会受限于框架设计，导致“怎么用框架做某事”的问题耗费大量时间。选一个后端系统更是困难，因为你经常不知道它的限制，直到真正使用时才发现。

bknd 的解决方案是： 实现最基础的后端功能，基于 Web 标准设计，适配多种运行环境，避免锁死在某个技术或平台。

1. 数据库锁定（Database lock-in）

很多后端系统只能用某个数据库（如只支持 Postgres 或 MongoDB），但数据库往往是最难扩展和维护的部分。SQL 数据库稳定且被广泛接受，但 NoSQL 灵活且易扩展。bknd 选择把 SQLite（最简单的 SQL）作为存储和查询接口，把业务逻辑和数据验证放到应用层，这样：

• 可以支持多种数据库（理论上任何 SQL 都可）
• 验证逻辑可以复用到客户端和服务端，避免无效请求进入服务器
• 数据完整性检查靠应用层处理，方便迁移到如 PlanetScale 这类新型数据库

2. 环境和框架锁定（Environment and framework lock-in）

很多后端绑定某个前端框架（比如只支持 Next.js），这限制了开发者的选择。bknd 选择用最通用的 Web API（workerd），避免 Node.js 专属功能的依赖，使得后端能运行在任何 JavaScript 环境（包括 Node、Bun、Cloudflare Workers 等），甚至直接嵌入前端框架中，实现前后端统一部署。

3. 偏离标准（Deviation from standards）

一些后端实现自定义认证头或者不符合 HTTP 标准的查询参数格式，导致很多 HTTP 客户端无法兼容。bknd 遵守 Web 标准，同时提供便捷的参数用法（比如支持 ?select=id&select=name 和 ?select=id,name 两种写法）。

如果用户发现 bknd 在标准支持上有缺陷，鼓励反馈改进。

4. 不适用的默认实现（Wrong-for-your-use-case implementations）

后端系统常集成诸如邮件验证、密码重置等功能，但不同应用需求差异很大，比如邮件验证码的形式和长度。bknd 认为这些属于业务逻辑，而不是核心后端功能，因此只提供强大的事件机制和工作流系统，允许用户自由定制验证流程，做到既灵活又强大。

5. 自托管复杂度（Complex self-hosting）

如果系统难以自托管，厂商就能强迫用户用它的云服务，虽然这对厂商有利，但对用户和厂商都增加成本。bknd 设计简洁，易部署。只要会部署 Next.js、Remix、Astro，就能部署 bknd，也支持 Cloudflare Workers，甚至只需28行 Dockerfile。

总结

bknd 旨在打造一个轻量、标准、灵活且多环境兼容的后端系统，避免技术锁死，易于自托管和扩展，助你专注业务逻辑开发，摆脱繁琐的底层实现。