HN讨论 · 身份未知
单文件夹 TypeScript 后端：避开 RLS/SQL 授权与实时优先数据库模型
作者在体验 Supabase 与 Convex 后指出一个具体缺口：快速起库和认证的后端，要么用 RLS/SQL 写授权，要么被不喜欢的数据库模型和实时优先默认约束。Typebase 以单个 typebase/ 文件夹提供 schema.ts、类型安全函数调用和内建认证，一条 CLI 即可部署到多个平台，作为这一取舍的差异化回应。
查看原始信号hn:49447178
目标用户
偏好 TypeScript 全栈开发、希望后端代码贴近前端且不想被特定 BaaS 或数据库模型锁定的独立开发者与小团队。
潜在需求
需要一种后端方案：像 Supabase 一样能快速起数据库和认证，又能像 Convex 一样让服务器代码与前端代码类型安全共生，但不需要用 RLS/SQL 写授权，也不采用不喜欢的数据库模型和实时优先默认值。
发生场景
作者在选用后端服务时，喜欢 Supabase 快速提供数据库和认证，但授权必须用 RLS 和 SQL 编写；喜欢 Convex 让服务器代码“活”在代码里，但不喜欢其数据库模型和实时优先的默认值。
来源证据
作者表示，他喜欢 Supabase 快速搭建数据库和认证，但不喜欢用 RLS 和 SQL 做授权；喜欢 Convex 的服务器代码与代码共生，但不喜欢其数据库模型和实时优先的默认设计。
Hey HN! I built Typebase, a library that gives you Convex's DX with Supabase's openness. After trying Supabase I liked how fast it is to spin up a DB and auth, but really didn't like using RLS and SQL for authorization. With Convex I loved how your server "lives" in your code, but disliked the DB model and the realtime-first defaults. With Typebase you just write TS files inside a typebase/ folder in your existing repo. You can define your DB tables inside a schema.ts file and export serverhttps://news.ycombinator.com/item?id=49447178
为什么值得留意
该信号不是泛泛功能列表，而是作者在使用两个现有后端产品后总结出的具体取舍：对 Supabase 的授权写法和 Convex 的数据库模型均有明确不满，并通过 Typebase 给出了一个可检查的替代形态。“要 A 的开放性 + B 的开发体验”这类偏好可能吸引同样取舍的开发者，值得持续跟踪采用反馈。
已有方案
- Supabase
- Convex
未满足部分
- Supabase 的授权需要写 RLS 和 SQL，作者不喜欢这条路径
- Convex 的数据库模型与实时优先默认值不符合作者偏好
可能延伸 · 模型推测
- 将 Typebase 的 schema 与现有 Supabase/Convex 项目互转的迁移工具
- 为更多部署平台（如自托管 Node 服务）生成代码或插件
- 在 typebase/ 中增加迁移与版本管理机制
目前未知
- 信号来自项目作者自述，缺少独立第三方用户的使用反馈
- 作者对 Supabase/Convex 的不满属于个人偏好，不代表其他开发者也有同样痛点
- Typebase 目前评论与热度为零，尚未验证其生态或持续维护情况
继续核实
- 其他开发者在 Supabase 或 Convex 上是否也遇到类似的授权或数据库模型痛点？
- Typebase 的单文件夹后端在实际项目中能否处理复杂权限、多环境和规模增长？
- 哪种类型的应用最适合采用这种“单文件夹后端”方式？
主题词
typescript backendbackend authorizationdatabase schemaserver functionsfrontend type safety