PRD 与文档驱动开发
3.3 前后端分离概念
Tip
理解前后端分离的概念,学会用API连接前端和后端,避免写出混乱的意大利面代码。
1. 为什么要学这个?
新手最容易写出意大利面代码:HTML里混着JavaScript,JS里混着SQL,CSS里还藏着PHP逻辑。一团乱麻,动一根面条,整个盘子都在抖。
想象你经营餐厅。
- 大排档模式:老板既炒菜又端菜,厨房就在餐桌旁边,油烟满天飞。你想换张桌子?得先把灶台拆了。
- 米其林模式:厨房和大堂分开,厨师专心炒菜,服务员专心端菜。想换装修?不影响厨房。想换菜单?不影响大堂。
关键问题:
- 前端和后端分别负责什么?
- 为什么要分离?
- Next.js怎么做前后端分离?
前后端分离就是让厨房和大堂各司其职。
2. 核心概念
2.1 前端 - 餐厅大堂
技术定义:前端(Frontend)负责用户界面和交互,运行在用户的浏览器中。
就像餐厅大堂。
- 职责:装修(CSS)、接待客人(UI)、把菜端上来(Rendering)
- 不负责:炒菜(业务逻辑)、库存管理(数据库)
- 技术栈:Next.js、React、Vue、Tailwind CSS
2.2 后端 - 封闭厨房
技术定义:后端(Backend)负责业务逻辑和数据处理,运行在服务器上。
就像封闭厨房。
- 职责:切菜(数据处理)、炒菜(业务逻辑)、库存管理(数据库)
- 不负责:端菜(UI渲染)、装修(样式)
- 技术栈:Node.js、Go、Python、PostgreSQL、Prisma
2.3 API - 传菜口
技术定义:API(Application Programming Interface)是前端和后端之间的接口,用于数据交换。
就像传菜口。
- 工作方式:前端喊"3号桌要宫保鸡丁(JSON Request)",后端递出来"给,宫保鸡丁(JSON Response)"
- 关键点:前端不需要知道后端怎么做菜,后端不需要知道前端怎么摆盘
graph LR
A[前端/大堂] -->|HTTP请求| B[API/传菜口]
B -->|JSON数据| C[后端/厨房]
C -->|JSON数据| B
B -->|HTTP响应| A
D[用户] -->|点击按钮| A
A -->|显示数据| D
C -->|查询| E[数据库]
E -->|返回| C
style A fill:#e1f5ff
style B fill:#fff3e0
style C fill:#f3e5f5
style E fill:#e8f5e9
3. Next.js的特殊性
Next.js把"前店后厂"开在了一起,但逻辑必须分离。
app/
├── page.tsx # 前端组件(大堂)
├── api/
│ └── route.ts # 后端接口(厨房)
└── actions/
└── user.ts # Server Actions(厨房)
铁律:
- ❌ 不要在
page.tsx(前端)直接连数据库 - ✅ 必须通过API或Server Actions进行数据交互
// ❌ 错误:在前端组件直接查数据库
export default async function Page() {
const users = await prisma.user.findMany() // 危险!
return <div>{users.map(...)}</div>
}
// ✅ 正确:通过Server Action
export default async function Page() {
const users = await getUsers() // Server Action
return <div>{users.map(...)}</div>
}
4. 什么时候需要分离?
| 🎯 场景 | 是否分离 | 理由 |
|---|---|---|
| 纯静态博客 | ❌ 不必 | 内容固定,不需要动态数据 |
| 现代化Web App | ✅ 必须 | 交互复杂,数据动态,必须分工明确 |
| 多端应用(Web+App) | ✅ 必须 | App和网页共用同一个后端API |
5. 避坑指南
| ❌ 不要这样做 | ✅ 应该这样做 | 为什么 |
|---|---|---|
| 在组件里写SQL | 只在Server Actions里操作数据库 | 安全漏洞,等于把钥匙贴在门上 |
| 前端计算税率,后端也计算 | 后端负责逻辑,前端只展示 | 避免逻辑重复和不一致 |
| 前后端逻辑混在一起 | 严格分离,通过API通信 | 方便维护和重构 |
6. 真实案例
Story
2010年,Twitter的Fail Whale消失之谜
2010年左右,Twitter经常崩溃,出现著名的"Fail Whale"(一只被鸟提着的鲸鱼画面)。原因是早期Twitter是一个巨大的Ruby on Rails单体应用,前端渲染和后端逻辑紧紧缠绕在一起,每当流量暴涨,整个系统就一起挂掉。为了解决这个问题,Twitter工程团队做了彻底的前后端分离:把前端完全重写成纯JS客户端,把后端拆分成独立的API服务。结果"Fail Whale"消失了,这种架构让Twitter支撑住了后来100倍、1000倍的用户增长。
Vibe心法:即便在Next.js这种"一体化"框架中,前后端逻辑分离依然是不可触碰的红线——前端只管显示,后端只管逻辑。
7. 本章小结
- 🏠 前端是大堂:负责UI和交互,运行在浏览器
- 🍳 后端是厨房:负责业务逻辑和数据,运行在服务器
- 🛎️ API是传菜口:前后端通过JSON数据交换
- 📁 Next.js特殊性:虽然在一个项目里,但逻辑必须分离
- ⚠️ 铁律:前端不直接连数据库,必须通过API或Server Actions