第 7 章：架构师的十字路口：BaaS vs. ORM

欢迎来到第四部分。在这里，我们将从 "如何实现" 暂时跳出，进入 "为何这样选" 的架构师思维。对于一个全栈 SAAS 应用，有两个最关键的决策将决定你的开发速度、扩展性和长期成本：数据库和认证。

在 Python 后端世界中，这个选择相对“固定”：Django 开发者通常会选择 Django ORM + Django Auth。Flask 开发者可能会选择 SQLAlchemy + JWT。

但在 Next.js 全栈生态中，你正站在一个十字路口。你有两条截然不同的路可选，它们都非常流行，但代表着完全不同的开发哲学。

7.1. 为什么是架构选型？(性能、锁定、灵活性)

这个选择之所以重要，是因为它深度绑定了你的后端架构：

1. 性能与扩展性：尤其是在 Serverless 环境下（如 Vercel），数据库连接管理是一个巨大的性能瓶颈。你的选择能否高效处理数千个短暂的 serverless function 连接？
2. 供应商锁定 (Vendor Lock-in)：你选择的服务是否将你的数据和认证逻辑“锁定”在其平台上？如果未来需要迁移，成本有多高？
3. 灵活性与控制力：你对数据库 schema、查询性能和认证流程有多大的控制权？当 SAAS 业务逻辑变得复杂时，你选择的工具是否会成为瓶颈？

让我们来深入分析这两条路径。

7.2. 路径 A：BaaS 模式 (Supabase)

BaaS (Backend as a Service) 模式的杰出代表是 Supabase。

你可以将 Supabase 视为 "开源的 Firebase"，但它构建在你熟悉的 PostgreSQL 之上。它不是一个库，而是一个平台，为你打包提供了构建后端所需的一切。

7.2.1. 优势：极速开发、自带 Auth、实时、RLS

选择 Supabase，你几乎在第一天就能获得一个完整的后端：

• 极速开发：你不需要单独配置数据库、写认证 API、设置对象存储。一切都已准备就绪。
• 自带 Auth：Supabase 内置了完整的用户认证系统（JWT、OAuth、Magic Links），深度集成了数据库。
• 实时 (Realtime)：可以“订阅”数据库的变更。例如，你可以轻松实现一个多人协作或实时通知功能，而无需自己搭建 WebSocket 服务器。
• 存储 (Storage)：内置了 S3 兼容的对象存储，用于处理用户上传的图片或文件。
• RLS (行级别安全)：这是 Supabase 的核心，我们稍后详述。

对于 Python 开发者来说，这就像你获得了一个“超级 Django”，它不仅有 ORM 和 Auth，还内置了 S3 和实时功能，并且是完全托管的。

7.2.2. 核心实践：行级别安全 (RLS) (Rule 2)

这是 Supabase 哲学的关键。在传统的 Django/Flask 应用中，你的安全逻辑写在哪里？ 写在应用层（views.py）：

# Flask/Django 的应用层安全
def get_project(project_id):
    project = Project.objects.get(id=project_id)
    if project.owner_id != g.user.id:  # 在代码中检查权限
        abort(403)
    return project.to_json()

Supabase (和 RLS) 的哲学是：安全策略应该在数据库层执行。

你直接用 SQL 定义策略：

-- Supabase RLS 策略 (SQL)
CREATE POLICY "用户只能查看自己的项目"
ON projects FOR SELECT
USING ( auth.uid() = owner_id ); -- auth.uid() 是 Supabase 提供的函数

启用 RLS 后，当一个认证用户执行 SELECT * FROM projects 时，PostgreSQL 数据库会自动过滤，只返回 owner_id 等于当前用户 ID 的行。

优势：你的应用层代码（无论是 Next.js 还是其他）变得极其简单。你甚至可以直接从客户端安全地查询数据库，因为安全策略已在数据库中强制执行。

7.2.3. 核心实践：连接池 (PgBouncer) (Rule 1)

这是 Serverless 架构的关键痛点。

• 问题：Vercel 上的 Serverless Function 是短暂的。每次 API 请求（或 Server Action）都可能创建一个新的 function 实例。如果每个实例都打开一个新的数据库连接，你的 1000 个并发用户可能会瞬间耗尽数据库的 100 个连接限制，导致应用崩溃。
• 传统方案 (Python)：在 WSGI/ASGI (如 Gunicorn) 中，你有一个长期运行的进程池，可以维护一个持久的数据库连接池 (如 SQLAlchemy 的 Pool)。
• Supabase 方案：Supabase 内置了 PgBouncer，这是一个轻量级的连接池管理器。你的 Serverless Function 实际上是连接到 PgBouncer，PgBouncer 再去管理与真实 Postgres 数据库的少量持久连接。

结论：Supabase 是一个强大、“电池全包”的平台，尤其适合快速启动项目和需要实时功能的团队。

7.3. 路径 B：ORM 模式 (Drizzle) - [本书实战项目选择]

现在，我们来看另一条路：自建（Bring Your Own） 栈。这条路不依赖于单一平台，而是将各个“最佳”组件组合起来。

• 数据库：任意 Postgres 供应商 (Neon, Vercel Postgres, AWS RDS...)
• ORM：Drizzle ORM (我们的选择)
• 认证：Better Auth (Auth.js) (我们将在下一章讨论)

7.3.1. 优势：完全控制、类型安全、SQL 接近度、无供应商锁定

选择 Drizzle 代表了一种不同的哲学：“我希望完全掌控我的栈，并获得极致的类型安全和性能。”

1. 完全控制：你没有被“锁定”在 Supabase 平台。明天你想从 Vercel Postgres 换到 Neon，或者自托管 Postgres？没问题，你的代码一行都不用改。
2. SQL 接近度：Drizzle 不是一个像 SQLAlchemy 或 Prisma 那样的“重型” ORM。它是一个 TypeScript Query Builder。你写的 Drizzle 代码几乎 1:1 映射到 SQL 语句。
   • Python 对比：SQLAlchemy ORM 抽象度很高 (user.projects.append(p))。Drizzle 更像是 SQLAlchemy Core，你写的更接近 SQL (db.select().from(users).where(...))。
   • 优势：没有复杂的 ORM 黑盒，性能易于预测，你可以使用所有 Postgres 的高级功能。
3. 极致的类型安全：这是 Drizzle 战胜所有对手（包括 SQLAlchemy）的王牌。Drizzle 的 drizzle-kit 工具会自动根据你的 Schema 推断出所有查询结果的 TypeScript 类型。
4. 无供应商锁定：Drizzle 只是一个库。你的认证 (Better Auth) 也只是一个库。它们可以独立升级、替换和配置。

7.3.2. [代码解析]：分析 src/db/ 中的 Drizzle Schema

在我们的实战项目中，src/db/schema.ts (或 src/db/schema/ 目录) 是我们唯一的“数据真实来源 (Single Source of Truth)”，它取代了 Django 的 models.py。

让我们看看它的样子：

// src/db/schema/users.ts
import { pgTable, text, varchar, timestamp, boolean } from "drizzle-orm/pg-core";
import { relations } from "drizzle-orm";
import { projectsTable } from "./projects"; // 导入其他表用于关系

// 1. 定义 Users 表
export const usersTable = pgTable("users", {
  id: varchar("id").primaryKey(), // 通常来自 Better Auth 的用户 ID
  name: text("name"),
  email: text("email").notNull().unique(),

  // 用于 Stripe 订阅
  stripeCustomerId: text("stripe_customer_id").unique(),
  stripeSubscriptionId: text("stripe_subscription_id").unique(),
  stripePriceId: text("stripe_price_id"),
  stripeCurrentPeriodEnd: timestamp("stripe_current_period_end"),

  // 用于 AI SAAS 点数
  credits: integer("credits").default(10).notNull(),
});

// 2. 定义 Users 表的关系
// Drizzle 将关系定义和表结构分开，保持 schema 清晰
export const usersRelations = relations(usersTable, ({ many }) => ({
  // 一个用户 (one) 可以有多个项目 (many)
  projects: many(projectsTable),
}));

// src/db/schema/projects.ts
import { pgTable, text, varchar, timestamp } from "drizzle-orm/pg-core";
import { relations } from "drizzle-orm";
import { usersTable } from "./users";

// 3. 定义 Projects 表
export const projectsTable = pgTable("projects", {
  id: varchar("id").primaryKey().$defaultFn(() => crypto.randomUUID()), // 自动生成 UUID
  name: text("name").notNull(),
  createdAt: timestamp("created_at").defaultNow().notNull(),

  // 4. 定义外键 (ForeignKey)
  ownerId: varchar("owner_id").notNull()
    .references(() => usersTable.id, { onDelete: "cascade" }), // 级联删除
});

// 5. 定义 Projects 表的关系
export const projectsRelations = relations(projectsTable, ({ one }) => ({
  // 一个项目 (one) 只属于一个用户 (one)
  owner: one(usersTable, {
    fields: [projectsTable.ownerId],
    references: [usersTable.id],
  }),
}));

关键点：

• 清晰的 SQL 映射：pgTable, varchar, timestamp 都直接对应 SQL 类型。
• 类型安全的关系：relations 定义了表之间的关系，Drizzle 会利用它来为你提供类型安全的 join 查询。
• drizzle-kit：定义好 schema 后，你会运行 pnpm db:push (一个脚本)，drizzle-kit 会自动将这个 schema 变更“推送”同步到你的 Postgres 数据库。

7.4. 结论：为什么我们的 SAAS 模板选择了 Drizzle (灵活性与控制力)

BaaS (Supabase) 提供了惊人的开发速度，但这是有代价的：你被锁定在其生态系统、其认证、其 RLS 逻辑和其托管方案中。这对于快速验证 MVP (最小可行产品) 非常棒。

但是，对于一个目标是长期演进、高度可定制的企业级 SAAS 模板来说，控制力和灵活性压倒一切。

我们选择 Drizzle + Better Auth + 任意 Postgres 供应商 的组合，因为：

1. 我们掌控数据：我们可以将数据库托管在任何地方，并使用所有 Postgres 高级功能，不受平台限制。
2. 我们掌控认证：我们可以自由定制认证流程（见下一章），而不受限于 Supabase Auth 的规定。
3. 我们掌控性能：Drizzle 的轻量级和 SQL 接近度让我们能写出最高效的查询，并与 Vercel Postgres 等 Serverless 数据库完美配合（它们也内置了连接池）。
4. 我们掌控类型：Drizzle 提供了从数据库到前端的、无与伦比的端到端类型安全。

这条路在第 1 天的配置工作量稍大，但它为我们在第 100 天和第 1000 天的扩展提供了无限的可能性。这，就是架构师的权衡。