前端技术演化史

全栈框架与BFF

Properties1
tags全栈, bff, trpc, nextjs, nuxt, apiroutes, 类型安全

14分钟阅读

🔗 全栈框架与 BFF

一句话定性

如果说跨端是前端”向旁边长”,全栈化就是前端”向下扎根”。从 Node.js 让 JS 第一次能写后端,到元框架把 API 端点和组件塞进同一个项目,再到 tRPC 用 TypeScript 的类型直接穿透网络——前端一寸寸把后端的职责收进自己的版图。它要的不是”也会写后端”,而是让数据从数据库到屏幕,全程在一套语言、一套类型、一个项目里贯通。

一、它是什么 & 出现的时代

“全栈化”不是一个产品,而是一条贯穿十余年的演化轨迹。它分成几个清晰的台阶,每一阶都比上一阶把前后端绑得更紧:

2009  [[Node.js]] ── JS 能跑在服务器上(全栈化的物理前提)
   │
   ↓  前后端分离时代:前端团队也能维护一个 Express/Koa 服务
   │
~2016 元框架 API routes ── Next.js / Nuxt
   │   "pages/api/*.ts 里写后端, 和你的页面组件并排放"
   │   前后端 = 同一个项目、同一个仓库、同一次部署
   ↓
~2018 BFF(Backend for Frontend)
   │   前端拥有一个专属后端层, 按 UI 需求聚合/裁剪数据
   ↓
~2020 tRPC ── 端到端类型安全
   │   删掉 REST/GraphQL 的 schema, 后端函数像本地函数一样被前端调用
   │   类型自动从后端流到前端(全靠 [[TypeScript]])
   ↓
~2023 RSC ── 边界从"网络请求"消融进"组件树"(详见 [[RSC与前后端边界模糊]])

这是 跨端与全栈演进史 的纵向主线

跨端(React-Native与移动跨端/小程序生态/Electron与桌面端)是前端横向征服更多平台;全栈化是前端纵向吞噬后端职责。两条线最终在”全栈元框架”里合流。

二、为什么会出现(解决上一代什么痛点)

前后端"两个世界"的撕裂之痛

  1. 两种语言、两套心智:前端 JS/TS,后端 Java/Go/PHP/Python。改一个功能要切换两种语言、两套工具、有时还要协调两个团队。
  2. API 契约是永恒的扯皮源:后端定义接口,前端消费。字段改了名忘了通知前端、文档与实现不同步、联调反复对接——前后端之间那条”网络边界”是 bug 和沟通成本的高发区。
  3. 类型断在网络边界:后端有类型、前端有类型,但数据穿过 HTTP 那一刻类型就丢了,前端只能凭文档和运气把 any 强转成期望的结构。
  4. SSR 的硬需求:SSG 回归后,渲染要在服务端发生,前端被迫需要一个能跑服务端逻辑、能在服务端取数的运行环境——这把前端推向了后端。

根本动机有三:掌控数据获取、SSR 需要、类型贯通。 前端发现:与其隔着网络和后端扯皮,不如自己把那段后端也拿过来写。

三、核心机制 & 为什么流行

台阶一:API routes —— 前后端进同一个项目

Node.js 提供了物理前提,而 Next.js / Nuxt 把它产品化:

"前端项目里直接长出后端端点" 

my-app/
├─ pages/
│   ├─ index.tsx        ← 前端页面组件
│   └─ api/
│       └─ user.ts      ← 后端 API 端点(同一个项目里!)

同一个仓库、同一种语言、同一次 deploy。前后端的物理隔阂第一次被打破。前端工程师可以独立交付一个”带后端”的完整功能,不必再等后端排期。

台阶二:BFF —— 前端拥有自己的后端

随着客户端变多(Web、移动、小程序),一个通用后端很难同时满足所有端的需求。BFF(Backend for Frontend) 模式应运而生:

BFF:为前端量身定制的"中间层" 

          ┌─── BFF (Web) ───┐
 Web ─────┤                 ├──► 各种后端微服务 / 数据库
          │  聚合 / 裁剪 /   │
 移动 ────┤  适配数据形状    │
          └─── BFF (移动) ──┘

后端微服务返回通用的、粗粒度的数据;BFF 层(通常由前端团队用 Node 编写)把它们聚合、裁剪成每个端 UI 真正需要的形状。 关键在于所有权:这一层归前端管,前端不必再为”少一个字段”去求后端改接口。这是前端职责扩张的标志性一步。

台阶三:tRPC —— 让网络边界”消失”

tRPC 的核心洞察:既然前后端都是 TypeScript,为什么还要写 schema?

传统做法(REST/GraphQL)要手写一份 API 契约(OpenAPI schema、GraphQL schema、或手动同步的类型),前后端各自对着它编码。tRPC 说:如果前后端是同一个 TypeScript 代码库,后端函数的类型本身就是契约,何必再写一遍?

// 后端:定义一个 procedure
const getUser = t.procedure.input(z.string()).query(({ input }) => db.user.find(input));
 
// 前端:像调本地函数一样调它,返回值类型自动推断,改了后端前端立刻红线报错
const user = await trpc.getUser.query("u_123");  // user 的类型 = 后端返回值类型

类型直接从后端”流”到前端,网络请求成了实现细节。 它不引入新的运行时协议,纯靠 TypeScript 的类型推断在编译期把前后端缝合起来——这是 TypeScript 类型贯通能力被推到极致的产物。

为什么流行

  • 消除了前后端最大的摩擦源:API 契约扯皮、类型断裂、联调成本,被”同一个项目 + 类型贯通”大幅消解。
  • 个人/小团队生产力爆炸:一个人用 Next.js + tRPC 就能端到端交付一个产品,无需后端配合。这与 2023-未来 AI时代 “个体生产力倍增”的趋势同向叠加。
  • SSR/取数天然顺滑:全栈框架让”在服务端取数再渲染”成了默认能力。

四、带来的新问题 / 副作用

前端职责膨胀,边界开始模糊

  1. “前端”的外延膨胀到失控:如今一个”前端”要懂组件、状态、SSR、缓存策略、数据库查询、鉴权、边缘部署、可观测性……”前端工程师”这个词正在失去清晰定义。 这是全栈化最深的二阶效应。
  2. 耦合换来便利,也换来脆弱:tRPC 把前后端类型紧耦合——爽,但也意味着前后端无法独立演进,且这套打法基本绑死 TypeScript 单语言全栈,后端想换语言就出局。
  3. BFF 的运维负担:多一层 BFF 就多一层要部署、监控、排障的服务,前端团队被迫承担起后端的运维责任。
  4. 边界模糊 = 心智负担转移而非消失:网络边界曾经显眼、可调试(看一眼 Network 面板);当它被”同项目函数调用”隐藏后,架构边界变得隐形,新人更难看清”哪段在服务端跑、哪段在客户端跑”——这个问题在 RSC 里被推到极致(详见 RSC与前后端边界模糊)。

第一性原理拷问:全栈化省掉的”前后端协作成本”,有多少只是被转移成了”一个人/一个团队要扛起前后端全部复杂度”的认知成本? 复杂度守恒,它只是换了个地方待着。

五、为什么会衰落 / 现状

全栈化没有衰落,正是当下的主旋律,并且在向更深的融合演进:

  • 全栈元框架成为默认起点:React 生态的 Next.js、Vue 生态的 Nuxt、新锐的 SvelteKit/Remix/SolidStart……”建一个新前端项目”几乎等于”建一个全栈项目”。
  • tRPC / 类型安全全栈成为 TS 团队的高效范式,与 Server Actions 等新机制融合。
  • 与边缘计算融合:全栈逻辑可以部署到离用户更近的 Edge 节点,SSR/取数延迟进一步降低(详见 渲染模式演进史 与 部署与托管演进史)。
  • 向 RSC 演进:全栈化的下一站,是让”前后端边界”从”网络请求”彻底下沉为”组件树里的一条线”——这就是 RSC与前后端边界模糊。

与 RSC 的关系

全栈框架(API routes/BFF/tRPC)做的是”让前端能方便地调用后端”——边界还在,只是更顺滑。RSC 做的是”让边界本身消失在组件里”——你不再”调用一个后端”,而是直接写一个”在服务端运行的组件”。全栈框架是 RSC 的铺路石:它先把前后端搬进同一个项目、同一种语言、同一套类型,RSC 才有可能把那条网络边界彻底内化。

六、对后续技术的影响(因果链)

前后端"两个世界": 两种语言 + API契约扯皮 + 类型断在网络边界 + SSR硬需求
        │
        ↓
[[Node.js]](2009): JS 能写后端 ── 全栈化物理前提
        │
        ↓
元框架 API routes(Next.js/Nuxt): 前后端同一个项目/仓库/部署
        │
        ├─► 多端需求 ──► BFF: 前端拥有专属后端, 按 UI 聚合/裁剪数据
        │
        ├─► 类型还是断在网络 ──► tRPC: 靠 [[TypeScript]] 让类型穿透网络
        │       └─► 删掉 schema, 后端函数像本地函数被调用
        │
        ├─► 副作用: 前端职责膨胀 + 边界模糊 + 复杂度守恒(只是转移)
        │
        └─► 边界还在但更顺滑 ──► 下一步: 让边界彻底消失
                │
                ↓
        RSC: 边界从"网络请求"下沉为"组件树里一条线" [[RSC与前后端边界模糊]]
                │
                ↓
        与 Edge / 数据获取融合 ──► [[渲染模式演进史]] / [[未来5到10年前端发展方向]]

历史地位

全栈化是前端纵向扩张的主轴。它让前端从”消费后端 API 的人”变成”端到端掌控数据流的人”,兑现了”一套语言、一套类型、一个项目统一前后端”的承诺。但它也亲手模糊了前后端的边界,让”前端”这一职业的内涵膨胀到空前——它既是前端权力的巅峰,也是前端身份焦虑的起点。 而它铺下的所有路,都通向同一个终点:RSC与前后端边界模糊。

🔗 同组:跨端与全栈演进史 | RSC与前后端边界模糊 | React-Native与移动跨端 | 小程序生态 | Electron与桌面端 🔗 运行时:Node.js | Deno | Bun 🔗 框架:React | Vue | 前端框架演进史 | Angular-2+ 🔗 语言:TypeScript | 渲染:渲染模式演进史 🔗 时代:2018-2023 工程化时代 | 2023-未来 AI时代 | 深度:未来5到10年前端发展方向

关系图谱

反向链接