前置知识
SaaS 新手：前端 vs 后端 vs 全栈
面向初学者的前端/后端/全栈解释，配合易懂的类比与现代 SaaS 技术栈示例。
前端 vs 后端 vs 全栈（快速介绍）
任何 Web 应用都有两部分：前端（用户看到的）和后端（让系统运转的）。全栈意味着两边都能做。下面用简单类比和真实 SaaS 栈来说明。
用餐厅类比理解
想象一家餐厅：
- 前端 = 餐厅大厅。装潢、菜单、桌椅、服务员，相当于 UI、布局和交互。
- 后端 = 厨房。做菜、管理食材，相当于服务端逻辑和数据库。
SaaS 也一样：良好的用户体验（大厅）+ 稳定的系统底座（厨房）。用户点击按钮后，请求进入“厨房”，结果回到界面。
图示想法：frontend（浏览器 UI）↔ backend（服务器+数据库）— 就像大厅 ↔ 厨房。前端在 SaaS 中的职责
前端负责用户所见的一切：
- UI/UX：页面布局、导航、表单、仪表盘、视觉设计。
- 交互：按钮、表单校验、弹窗、图表（常用 Next.js）。
- 与后端沟通：调用 API 读写数据。
- 性能与适配：加载速度、移动端响应、可访问性。
前端就是“可见层” — 参考 overview。
后端在 SaaS 中的职责
后端是系统引擎：
- 数据与数据库：使用 PostgreSQL 存储数据，借助 Drizzle ORM 做安全查询。
- 业务逻辑：权限、订阅状态、数据规则。
- API 与服务函数：如
src/app/api/...下的接口。 - 认证与授权：账户、会话、OAuth、权限（例如 Better Auth）。
- 计费与集成：连接 Stripe 或邮件服务。
一句话：后端负责数据与核心流程 — 更多见 guide。
全栈：两顶帽子
全栈开发能做前后端。按餐厅类比，就是既能设计菜单，又能招待客户，还能下厨房。SaaS 与初创中很常见：
- 资源效率：一个人可交付端到端功能。
- 迭代更快：减少交接、推进更快（why）。
- 全局视角：UI 和服务端问题更易排查。
- 学习价值：适合新手建立完整认知。
全栈不代表样样精通，多数人仍有“强项”。但像 Next.js 这样的框架让前后端边界更模糊。
前后端如何衔接（Sushi SaaS）
真实例子：Sushi SaaS 集成了 Next.js App Router、API routes、server components、Better Auth、Drizzle ORM + Postgres，以及 Stripe。
组合方式：
- 统一结构：页面（前端）与 API（后端）在同一仓库。
- TypeScript 类型共享：模型在 UI 和服务端复用。
- 数据获取顺滑：server components/handlers 通过 Drizzle 访问 DB。
- 认证集成：后端验证，前端处理状态与重定向。
- Stripe 计费：前端发起 checkout，后端创建会话、处理 webhooks 并写入 DB。
示例：登录流程（前端 + 后端）
- UI（前端）：访问
/login，看到表单。 - 提交：前端发送到后端（如 POST
/api/auth/login）。 - 认证（后端）：Better Auth + Drizzle 在 Postgres 中验证并创建会话。
- 响应：返回 redirect 或 JSON，跳转到 dashboard。
- 登录后：请求携带 session cookie，后端授权并返回用户数据。
需要复习可看 primer。
总结：选择你的路径（或两者）
- 前端 = UI、UX 与交互。
- 后端 = 数据、规则、安全与集成。
- 全栈 = 两者兼顾，尤其适合独立 SaaS。
不必一次精通全部。可以先从前端或后端入手，但做一次完整功能最能理解全流程。
如果想快速上手，Sushi SaaS 提供现代全栈基线，方便探索与快速交付。
保持前台体验，确保后台稳健。