mirror of
https://github.com/RaisFast/raisfast.git
synced 2026-09-23 16:02:25 +00:00
7.8 KiB
7.8 KiB
raisfast 技术架构与产品分析报告
日期:2026-05-08
1. 产品定位评估:顶尖(10/10)
1.1 三合一架构 — 全球首创
| 产品 | Headless API | Serverless | 桌面端 | 同一套代码 |
|---|---|---|---|---|
| Strapi | ✅ | 有限 | ❌ | ✅ |
| Payload | ✅ | Vercel | ❌ | ✅ |
| Directus | ✅ | ❌ | ❌ | ✅ |
| Sanity | ✅ | ✅ | ❌ | ✅ |
| Contentful | ✅ | ✅ | ❌ | N/A |
| Notion | ❌ | ✅ | ✅ (Electron) | ❌ 两套 |
| Obsidian | ❌ | ❌ | ✅ (Electron) | N/A |
| WordPress | 半吊子 | ❌ | ❌ | ❌ 两套 |
| raisfast | ✅ | ✅ | ✅ (Tauri) | ✅ |
三端叠加产生独特价值:用户随业务增长无缝迁移,数据和 API 不变,只是部署方式变了。
个人写博客 → 下载 Tauri 桌面端,SQLite 本地存储
流量增长了 → 一键推到 Serverless,数据迁移到 PostgreSQL
团队协作了 → 自部署到公司服务器,完全可控
同一个 CMS,同一种 API,同一个管理界面,三种运行方式。
1.2 护城河
不是某个技术点,而是组合本身。别人抄一个两个容易,三个一起抄等于重写。
2. 技术架构评估:优秀(8/10)
2.1 已做到的(很多团队做不到)
| 能力 | 实现方式 | 质量 |
|---|---|---|
| IO 抽象层 | Storage / CacheStore / SearchEngine / RateLimitStore / JobQueue trait | ✅ 干净 |
| 多数据库切换 | dialect 层 + Pool 别名 + FromRow 宏 + cfg-gated 类型 | ✅ 零改动切换 |
| 分层架构 | Handler → Service → Repository 严格执行 | ✅ 职责清晰 |
| 测试覆盖 | 992 个测试(788 单元 + 149 API + 32 集成 + 23 tauri) | ✅ |
| 可选多租户 | BUILTIN_TENANTABLE 环境变量控制,默认无 tenant_id | ✅ 设计巧妙 |
| SQL 方言适配 | translate() + now_fn() + ago_expr() + upsert_clause() 等 8 个辅助函数 | ✅ 完整 |
| Admin UI 嵌入 | Vite SPA + rust-embed 编译进二进制 | ✅ 单文件部署 |
| Schema 管理 | 首次启动自动建表 + 增量迁移文件 | ✅ 幂等安全 |
2.2 还没做到的(顶尖的差距)
| 短板 | 现状 | 顶尖标准 | 优先级 |
|---|---|---|---|
| 插件加载 | 文件系统监视 + 磁盘读取 | 应支持 DB/网络加载(serverless 兼容) | 高 |
| 搜索引擎 | Tantivy 单机文件索引 | 应有分布式选项(Meilisearch / ES) | 中 |
| 缓存 | 只有 MemoryCache(moka) | 应有 Redis 实现 | 高 |
| 限流 | 只有进程内 DashMap | 应有分布式限流(Redis) | 高 |
| Serverless | 设计文档完成,代码未实现 | 全平台适配器 | 高 |
| 集成测试 | 149 个 API 测试 | 顶尖项目通常 500+ | 中 |
| 性能基准 | 无 | 应有 k6/wrk 压测报告 | 中 |
| 可观测性 | 基础 Prometheus | 应有 OpenTelemetry 全链路追踪 | 低 |
| SDK | 无 | 应有 JS/Python/Go/Rust SDK | 中 |
| CLI 体验 | 基础子命令 | 应有 create-raisfast 脚手架 |
高 |
2.3 与顶尖项目的差距分析
差距不是架构,是完成度。
| 维度 | raisfast | Supabase(参考) |
|---|---|---|
| 核心架构 | ✅ 同等水平 | ✅ |
| SDK 数量 | 0 | 8 种语言 |
| CLI 工具链 | 基础 | 完整(migration / codegen / types) |
| 实时订阅 | 无 | WebSocket 实时 |
| 边缘函数 | 无 | Edge Functions |
| 文档 | 少量 | 300+ 页面 |
| 测试 | 992 | 3000+ |
| 社区贡献者 | 1 | 700+ |
Supabase 不是架构更厉害,是同样的架构打磨了 3 年。
3. 开源策略
3.1 Open Core 模式
开源(社区版)MIT / Apache 2.0 商业版 BSL 1.1
───────────────────────── ─────────────────────────
核心 API 引擎 SaaS 托管平台(raisfast.cloud)
Admin UI 多租户云管理控制台
SQLite / PostgreSQL / MySQL 插件市场(分发 + 计费)
插件引擎(WASM/JS/Lua) 企业级功能(SSO/SAML/Audit 合规)
Tauri 桌面端 SLA 保障 + 技术支持
Serverless 适配器 Cloudflare Workers 一键部署
CLI 工具 高级分析仪表盘
文档 优先级支持
3.2 为什么不怕 Fork
| Fork 的人 | 会发生什么 |
|---|---|
| 小团队自用 | 不会竞争,可能贡献 PR |
| 公司二次开发 | 维护 fork 成本巨大,最终回归上游 |
| 真正竞争者 | 需持续跟进每个版本,成本超过自己写 |
防止白嫖的武器不是协议,是生态壁垒:
第 1 层:社区惯性 — stars、贡献者、文档、教程
第 2 层:发布节奏 — 每周发版,fork 要每周合并
第 3 层:SaaS 体验 — raisfast.cloud 一键注册即用
第 4 层:插件市场 — 官方市场 + 计费
第 5 层:商业许可 — BSL 法律保护
3.3 BSL 1.1 协议
- 源码公开,社区可以看、学、贡献
- 不能用来做竞品托管服务
- 3 年后自动转 MIT,保持开源精神
参考:GitLab、MariaDB、CockroachDB、TimescaleDB 均用此模式。
4. 市场定位与对标
4.1 不是下一个 WordPress
WordPress 的成功靠的是 2003 年博客时代爆发的 timing + 20 年积累的生态。 raisfast 不应该对标 WordPress,应该对标 Supabase。
| 产品 | 定位 | 结果 |
|---|---|---|
| Supabase | 开源 Firebase 替代品 | $116M 融资,GitHub 75K stars |
| Cal.com | 开源 Calendly 替代品 | $32M 融资,GitHub 32K stars |
| Appwrite | 开源 BaaS | $27M 融资,GitHub 45K stars |
| Meilisearch | 开源搜索引擎 | $22M 融资,GitHub 47K stars |
共同特点:用现代语言重写一个旧品类,性能 10x 提升,开发者体验 10x 提升。
raisfast = 开源 Strapi/Payload/Directus 的 Rust 重写版 + Serverless + Desktop。
4.2 竞争优势矩阵
| 竞品 | 语言 | 性能 | Serverless | 桌面端 | 冷启动 | 插件 | 多 DB |
|---|---|---|---|---|---|---|---|
| Strapi | Node.js | 低 | 有限 | ❌ | ~500ms | JS | PG/SQLite |
| Payload | Node.js | 低 | Vercel | ❌ | ~500ms | JS | PG/Mongo |
| Directus | Node.js | 低 | ❌ | ❌ | ~800ms | JS | 多种 |
| Ghost | Node.js | 中 | ❌ | ❌ | ~600ms | 闭源 | MySQL |
| WordPress | PHP | 极低 | ❌ | ❌ | ~1s | PHP | MySQL |
| raisfast | Rust | 极高 | 全平台 | ✅ Tauri | <5ms | WASM/JS/Lua | SQLite/PG/MySQL |
5. 实施路线图
Phase 1:产品完成度(4 周)
| 周次 | 目标 |
|---|---|
| W1 | Serverless 适配实现(Phase 1-3 from docs/serverless.md) |
| W2 | Redis 缓存 + Redis 限流 + 性能压测报告 |
| W3 | CLI 脚手架(create-raisfast)+ Docker 镜像 |
| W4 | 英文文档 + 示例项目(Blog / Portfolio / Docs site) |
Phase 2:开源发布(2 周)
| 周次 | 目标 |
|---|---|
| W5 | GitHub 公开、README、贡献指南、行为准则 |
| W6 | HackerNews / Reddit / Twitter 发布,技术博客文章 |
Phase 3:社区建设(持续)
| 任务 | 节奏 |
|---|---|
| 版本发布 | 每两周 |
| 技术博客 | 每周 1 篇 |
| Discord/论坛 | 每日响应 |
| 插件市场 MVP | 发布后 2 个月 |
| SaaS 托管版 | 发布后 3 个月 |
6. 结论
核心判断
8/10 的架构 + 10/10 的产品定位 + 足够的完成度 = 现象级产品。
当前状态
站在正确的位置上,方向对、架构对、时机对。
下一步
不是再想架构,是把每个模块做到极致,然后发布。
先发优势不会等太久 — Strapi 和 Payload 都在融资扩张。
现在该动手了。