【后端实战】用 Supabase + React/TS 零成本构建高并发 Multi-Agent 服务

在当前的技术大环境下，AI 的进化速度快得让人目眩。说实话，看着各种强大的代码生成工具不断涌现，有时候真的会产生一种"梦想破灭"的无力感------那些曾经让我们引以为傲的底层编码技巧、手写 RESTful API 的经验，在 AI 面前正逐渐化为泡影，让人倍感过时。既然传统的 CRUD 堆砌已经失去了大部分壁垒，我们在做独立开发或测试新点子时，就更应该把精力聚焦在核心业务逻辑和 AI 交互上，而不是耗费几周时间去搞一套登录注册和数据库权限。

这就是我最近在用 React 和 TypeScript 搭建交互式历史论坛时，果断放弃自建后端，全盘接入Supabase 的原因。

今天就把这套技术栈的实战经验和踩坑记录分享出来，希望能帮大家在做原型开发时省下宝贵的时间。

1. 为什么是 Supabase？而不是 Firebase？

作为一个开源的 Firebase 替代品，Supabase 最吸引我的地方在于它的底层是原汁原味的 PostgreSQL。

在"回音堂"这个项目里，我的核心需求是让现代网友和 AI 驱动的古代历史人物在同一个帖子里跨时空"对线"。为了平衡严谨的历史事实设定与充满戏剧张力的现代互联网吃瓜文化，系统每天会产生大量结构极其复杂的 JSON 数据（比如 AI 角色的性格 Prompt 状态、多级嵌套的回复树）。

Supabase 提供的强类型支持和 PostgreSQL 原生的 JSONB 字段，配合前端的 TypeScript，做到了极致的前后端类型安全。修改表结构只需几句 SQL，爽感拉满。

2. 核心架构实战与避坑指南

🔐 Auth 身份验证与 RLS（行级安全）

论坛最烦人的就是写鉴权逻辑。Supabase 的 Auth 模块直接帮我省掉了这部分工作。在注册登录页，我只调用了一个 supabase.auth.signInWithOtp()，就实现了免密邮件验证登录。本站根本不需要记录任何用户密码，安全性直接交给第三方托管。

配合 PostgreSQL 强大的 Row Level Security (RLS)，我用两行 SQL 就锁死了权限：

sql 复制代码

-- 只有发帖人（或者拥有管理员角色的人）可以修改自己的帖子
create policy "Users can update their own posts."
  on posts for update
  using ( auth.uid() = user_id );

前端完全不需要写校验逻辑，哪怕有人绕过前端直接调接口，也会被数据库底层的 RLS 无情拦截。

⚡ Realtime 实时订阅机制

为了让论坛有那种"群聊"的沉浸感，当用户触发了某个历史人物（比如在帖子里 @诸葛亮），AI 调度器在后台生成回复后，需要立刻推送到前端。

利用 Supabase 的 Realtime 广播机制，前端只需要简单的监听事件：

typescript 复制代码

supabase
  .channel('public:posts')
  .on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'posts' }, payload => {
    // 实时将古人的回复渲染到页面上
  })
  .subscribe()

不用自己配 WebSocket，不用搞复杂的长连接，自带断线重连，对前端开发者极其友好。

🤖 Edge Functions 触发 AI 调度

在 Supabase 平台，我挂载了几个 Edge Functions（基于 Deno）。当 posts 表有新数据插入时（比如检测到历史名人被提及），利用 Webhook 触发 Edge Function，异步调用后端的大模型 API。这做到了业务逻辑的完全解耦，哪怕 AI 生成得很慢，也完全不会阻塞用户的发帖动作。

3. 挑战这套架构的极限

目前，这套基于 React + TS + Supabase 构建的"回音堂"沙箱已经上线跑了一段时间。系统里驻扎了一批极其嘴硬、带有古代局限性偏见的 AI 历史人物。

虽然 Supabase 宣称能处理极高的并发，但我还没有在真实的高压环境下测试过它的 Realtime 推送上限和 RLS 策略的边界。

🔗 压测地址：https://anachron.qizhen.xyz/

整个测试环境不需要大家注册，可以直接用游客身份体验。

如果有用过 Supabase 的大佬踩过什么坑，或者对这套全栈架构有优化建议，欢迎直接在帖子里探讨！