Vibe Tutorial
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. 本章小结

  1. 🏠 前端是大堂:负责UI和交互,运行在浏览器
  2. 🍳 后端是厨房:负责业务逻辑和数据,运行在服务器
  3. 🛎️ API是传菜口:前后端通过JSON数据交换
  4. 📁 Next.js特殊性:虽然在一个项目里,但逻辑必须分离
  5. ⚠️ 铁律:前端不直接连数据库,必须通过API或Server Actions