我为什么构建 ElysianDB
Source: Dev.to
早期后端决策的问题
大多数项目并不是因为缺乏想法而失败。
它们减速的根本原因是结构性的：后端决策要么过早做出，要么被推迟到不被任何人真正信任的 mock 之后。
在项目初期，团队希望保持动能。他们想探索功能、验证用户流程并快速迭代。但他们仍然需要一个行为像真实系统的后端——而不是在出现身份验证、权限或关联时就崩溃的脆弱 mock，也不是对几乎不存在的产品假设过多的完整架构。
这种张力既常见又代价高昂：
- Mock 往往会不断膨胀，最终看起来像一个没有保证的后端。
- 真实实现 常常从一套约束开始，而这些约束后来被证明是错误的。
在这两种情况下，团队最终都要重写大量已构建的部分，要么因为它本来就不该持久，要么因为它设计得太早。
介绍 ElysianDB
ElysianDB 正是为了解决这一空白而诞生。该项目使用 Go 编写，围绕一个简单的理念：让团队从第一天起就使用真实的后端，而不必锁定只能在产品更清晰后才决定的架构。
立即可用
- 从原始 JSON 开始。
- 使用即用的 API 存储文档。
- 无需脚手架即可获得 CRUD 端点。
- 查询是真实的，持久化是真实的，身份验证和访问控制从一开始就被强制执行。
- 前端与实际系统交互，而不是占位符。
连续性胜于过早优化
在项目早期，ElysianDB 依赖一个快速且轻量的内部存储引擎，旨在实现快速迭代、最小化设置和低摩擦。此阶段的优先级是反馈速度和安全转向的能力——而非最大耐久性或水平可扩展性。
随着项目演进：
- 数据量增长。
- 可靠性变得关键。
此时无需重新设计后端或迁移 API，ElysianDB 允许存储层演进。通过切换配置，同一套 API 可以运行在 MongoDB 上。端点保持不变，契约保持稳定，前端无需适配。系统在不破坏已有构建的情况下成长。
行为与权限
ElysianDB 通过 hooks（钩子）和 access control lists (ACLs)（访问控制列表）来处理动态行为和安全。
Hooks（钩子）
- 使用 JavaScript 编写。
- 在读取时执行。
- 允许在不修改存储文档或过早嵌入业务逻辑的情况下动态丰富或转换数据。
ACLs（访问控制列表）
- 明确定义权限。
- 始终如一地强制执行，避免在上线后再补丁式地加入安全措施。
两者均通过基于 Web 的管理界面进行管理，使复杂性在系统演进过程中可视化并可调节。
当前状态
ElysianDB 仍在积极开发中。它尚未成为成熟、全方位的后端解决方案，也不声称自己是。它的目标是降低后端摩擦，而不是假装复杂性不存在。
- 不是 精心构建的领域驱动系统的替代品。
- 不是 大型后端平台的竞争者。
- 目标：在项目早期提供可信赖的后端，保持其诚实性，等到决策有足够依据时再做不可逆的选择。
行动号召
如果这种构建方式与你产生共鸣，我真的很想知道你会在哪些场景使用 ElysianDB——以及哪些场景不会使用。