从 Supabase 到 Clerk 再到 Better Auth

# 从 Supabase 到 Clerk 再到 Better Auth 来源：https://blog.val.town/better-auth lock-watercolor 2023 年，我写过一篇文章，讲的是 Val Town 如何从 Supabase 迁移（https://blog.val.town/blog/migrating-from-supabase）到更传统的数据库方案。当时我们大量使用了 Supabase 的功能，包括身份认证。所以迁移时我们找了替代品：数据库用 Render（https://render.com/），身份认证用 Clerk（https://clerk.com/）。但计划赶不上变化，到了 2023 年底，有人提了一个 issue：摆脱 Clerk。这个 issue 一个月前终于关闭了，因为我们切换到了 Better Auth（https://www.better-auth.com/）。 需要说明的是，Clerk 非常成功。他们刚刚融了 5000 万美元（https://clerk.com/blog/series-c），而且有很多满意的用户。顺带一提，Supabase 也以 50 亿美元估值融了 1 亿美元（https://supabase.com/）。恭喜他们。我要是做风投肯定不行。不管我对身份认证和行级安全有什么看法和经验，在这些数字和成绩面前都不那么重要。你没法反驳成功。 但尽管如此，我还是很高兴关闭了那个 issue，切换到了 Better Auth。这一路并不容易，充满了各种变通办法、Bug 和故障。Val Town 的架构和 Clerk 的预期严重冲突。 ### 核心问题 核心问题在于，Clerk 试图既当你的用户表，又当你的会话表。我感觉他们现在不再这么强调了，但一开始确实很极端：2021 年有篇博客叫“考虑删除你的用户表（https://clerk.com/blog/offload_user_table）”。2023 年还有个 YouTube 视频叫“删除你的用户表（https://www.youtube.com/watch?v=86sFORO-M3Y）”。我强烈建议你不要这么做！ 把用户表外包给第三方服务有两个大问题。 **Clerk 作为用户表的替代品相当糟糕，因为它有严格的速率限制，而且不太可靠。** 我们刚切换时，以为可以随时通过 Clerk 的 API 加载用户数据。毕竟我们想知道的用户信息，比如设置、头像 URL、邮箱等。Clerk 的 SDK 让这挺方便：`rootAuthLoader`（处理整个应用认证的东西）有一个不错的选项叫 `loadUser`，可以帮你完成请求。开发环境完美运行。生产环境下，那个端点的速率限制是*每秒五次请求*，针对整个账户，所有用户共享。太棘手了！这是个很坑人的陷阱，我们在生产环境中才发现，最终通过移除这个选项才修复（https://github.com/clerk/javascript/issues/1043）。 速率限制对我们打击尤其大，因为 Val Town 有社交功能。比如，一个社交网站，很多页面会展示其他用户的内容列表，以及用来标识用户的用户名和头像。Clerk 的默认 UI 假设用户只会看到*自己的头像*，只需要自己的设置和信息，而这些都可以通过他们精巧的 JWT（https://datatracker.ietf.org/doc/html/rfc7519）令牌获取。像 Val Town 这样的社交网站完全打破了这种假设，而官方的建议是在 Clerk 和我们的用户表之间同步头像和其他信息：于是我们有了两个信息权威来源，以及两个用户表的复杂性。 所以我们不得不通过 webhook 将 Clerk 的数据同步到数据库，这意味着注册流程变得复杂而棘手——用户会有一小段时间拥有 Clerk 账户但没有 Val Town 数据库行。或者，由于我们的平台要求用户名，用户可能处于拥有 Clerk 账户、数据库行，但账户不完整的状态。用户设置不得不拆分成两部分：一部分由 Clerk 控制（比如认证策略），另一部分由我们控制（比如用户名和编辑器设置）。 **第二个问题是，Clerk 成了我们所有用户会话的单点故障。** 基于 cookie 的用户会话通常寿命短、频繁刷新，这样就能快速失效。但这也意味着每隔几分钟用户就需要用新会话 cookie 替换旧的。所以当登录会话需要刷新时，是由 Val Town 的一个子域名将请求转发给 Clerk 来完成的。我们没有会话表，也不对会话负责。 这很好，如果你不想承担任何认证责任的话。但另一方面，如果 Clerk 宕机，整个网站就挂了。Clerk 的故障不仅影响登录登出流程，还会让已经登录的用户也无法使用网站。而且 Clerk 宕机相当频繁，持续时间也很长。自 2025 年 5 月以来（https://status.clerk.com/），它的正常运行时间就在两个九和三个九之间摇摆。之前没有数据，但我记得很多次因为单点故障，网站崩溃而我们毫无办法。 在构建复杂系统时，你会深刻认识到一个教训：系统的可靠性取决于其关键部分可靠性的*最小值*。 除了这两个主要问题，我们还遇到过其他 Bug 和问题（https://github.com/clerk/javascript/issues?q=sort%3Aupdated-desc%20is%3Aissue%20state%3Aclosed%20author%3Atmcw）。大多数最终都修复了，但我花了很多时间跟“Stale Issue Bot”作斗争，防止它自动关闭 issue。 ### 大约三年 如果这么糟糕，为什么我们不立刻切换？ 首先，尽管这将是我写的第二篇“从 X 切换到 Y”的文章，但我并不想养成这个习惯。做出决定并坚持下去，对开发速度和团队稳定性都有好处。我们不会在非必要的情况下重写 Val Town。而且写批评性文章不如构建东西有趣和积极。 不过，Clerk 确实有一些做得好的地方。他们为我们的技术栈（Remix、Fastify、Express）都提供了 SDK。他们还很好地跟上了这些框架的更新节奏，这个任务我知道是全职工作。他们的管理和反滥用措施在帮助解决客户支持问题和防止诈骗方面也还不错。 Clerk 的强项在于相对简单、以前端为主、没有社交功能的应用，这样就不需要用户表。上手非常容易，价格实惠，Clerk 的控制台也相当不错。 而且，优秀的身份认证选项并不多。替代 Clerk 的门槛其实很高：很多开源身份认证方案都古老且半废弃。身份认证即服务平台则存在供应商风险，而且可能和 Clerk 有相同的问题。技术控制的合适粒度很难把握。我们不想从头构建身份认证，给 Val Town 带来新的、尴尬的漏洞，但也不想把太多责任甩给供应商。绝对不再信任第三方的会话管理了。 ### Better Auth 登场 Better Auth（https://better-auth.com/）从一开始就满足了很多条件：代码质量高、与不同框架集成良好、作为独立开源项目真正可用。 供应商风险依然存在：它是一个庞大复杂的代码库，主要由一家公司开发。供应商风险永远存在。但我们现在不再依赖第三方在线来保证会话和用户认证的正常工作。 第二候选是 WorkOS（https://workos.com/）的 AuthKit（https://www.authkit.com/）。我信任 WorkOS，AuthKit 也极其流畅，但在两家供应商之间来回折腾之后，对我来说，找到一个能独立工作、核心开源的东西很重要。 我觉得 Better Auth 的控制台和付费插件也很巧妙。我们自己管理所有数据，一个插件在我们的网站上提供 API，让他们的控制台可以拉取信息并进行一些轻量级的用户管理。Better Auth 的付费服务（称为“Infrastructure”）在我们使用方式下基本是无状态的，不参与会话管理。 简而言之，到目前为止，确实更好。 而且，我不得不承认大语言模型的作用：在机器人的辅助下，我们能够采取更复杂的路线，在两周的过渡期内同时支持 Better Auth 和 Clerk。每个处理认证的端点都接受两种 cookie，用户逐渐迁移到 Better Auth，因为登录页面提供的就是 Better Auth 的会话。和任何安全相关的事情一样，我们需要仔细阅读、重写和测试所有代码，以确保不会自食其果，最终纯 Better Auth 的认证代码完全是手写的。 Better Auth 也和 Vals 配合得很好：你可以试试 Better Auth 启动模板（https://www.val.town/x/templates/better-auth-starter），为你在 Val Town 上的代码添加身份认证。 --- 这一路我学到了很多。你的正常运行时间真的很依赖上游提供商，你应该认真思考自己暴露在这种风险下的程度。产品可能对很多用例都很好，也很成功，但仍然不一定适合你的特定问题。软件世界变化很快，正确的解决方案可能在你需要的时候不存在，但一年后可能就出现了。