BFF on acye's blog

BFF 的简单实现:用 Node 给前端做一个中间层

Fri, 11 Sep 2026 09:40:00 +0800

BFF(Backend For Frontend)是前端进阶最值得先做的实践:用一个 Node 服务,专门为前端页面拼数据。

BFF 是什么

BFF 全称 Backend For Frontend(为前端而生的后端),最早由 SoundCloud 提出。它不是一个框架,而是一种架构模式:在前端和后端之间,加一个只服务前端的中间层。

为什么需要它?因为后端接口是为"所有客户端"设计的,而你的页面有特殊需求:

痛点	后端视角	BFF 解决方式
接口太碎	用户、订单、优惠券是三个接口	聚合成一个页面接口
数据冗余	返回 20 个字段,页面只用 5 个	裁剪字段,只给前端要的
协议不适配	返回 XML / 分页结构复杂	转成前端友好的 JSON
敏感字段	接口直接暴露内部字段	BFF 层过滤脱敏
跨域麻烦	前端直连多个域	统一从 BFF 同域转发

简单说:BFF 是前端的"专属外卖",后端是大食堂,你不想自己跑三个窗口打菜。

环境准备

用 Express 搭一个最简 BFF:

1
2
3

mkdir bff-demo && cd bff-demo
npm init -y
npm install express

场景:页面需要聚合三个接口

假设后端已有三个内部接口(或者用 JSON 模拟):

GET /internal/user → 用户信息
GET /internal/orders → 订单列表
GET /internal/coupons → 优惠券

前端页面一次要全部数据。直接让前端调三个接口再拼,会带来:请求慢(串行)、逻辑散落前端、接口地址暴露内部域名。

BFF 实现:聚合 + 裁剪

// server.js
const express = require('express');
const app = express();

// 模拟后端内部接口(真实场景用 fetch 调内部服务)
const mockApi = (data, delay = 100) =>
  new Promise((resolve) => setTimeout(() => resolve(data), delay));

async function getUser(id) {
  return mockApi({ id, name: 'acye', phone: '138****0000', email: 'a@b.com', _internal: 'secret' });
}
async function getOrders(id) {
  return mockApi([{ id: 1, title: '订单A', price: 99 }, { id: 2, title: '订单B', price: 199 }]);
}
async function getCoupons() {
  return mockApi([{ id: 'c1', amount: 20 }]);
}

// 页面聚合接口:BFF 的核心
app.get('/api/page/home', async (req, res) => {
  const userId = req.query.userId || 1;

  // 并行请求,三个接口同时发,总耗时 = 最慢的那个
  const [user, orders, coupons] = await Promise.all([
    getUser(userId),
    getOrders(userId),
    getCoupons(),
  ]);

  // 裁剪字段:只给前端要的,内部字段不外泄
  res.json({
    user: { id: user.id, name: user.name, phone: user.phone },
    orders: orders.map((o) => ({ id: o.id, title: o.title, price: o.price })),
    coupons,
  });
});

app.listen(3000, () => console.log('BFF listening on http://localhost:3000'));

启动后,前端只需要:

`1`	`const data = await fetch('/api/page/home?userId=1').then((r) => r.json());`

一个请求拿到全部数据,而且页面代码里完全不知道内部接口的存在。

进阶:超时、错误兜底与缓存

真实场景里,内部接口可能很慢甚至挂掉,需要加保护:

const withTimeout = (p, ms = 3000) =>
  Promise.race([
    p,
    new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), ms)),
  ]);

app.get('/api/page/home', async (req, res) => {
  const userId = req.query.userId || 1;

  try {
    const [user, orders, coupons] = await Promise.all([
      withTimeout(getUser(userId)),
      withTimeout(getOrders(userId)),
      // 优惠券挂了不影响主流程
      getCoupons().catch(() => []),
    ]);

    res.json({ user, orders, coupons });
  } catch (err) {
    // 聚合失败时给一个兜底,而不是让前端白屏
    res.status(502).json({ error: 'upstream error', detail: err.message });
  }
});

要点:

Promise.all 并行请求,避免串行累加耗时
Promise.race 做超时控制,防止内部接口拖死页面
非关键数据用 .catch(() => []) 降级,保证主流程可用
统一错误出口,前端只需处理一种错误结构

什么时候不需要 BFF

BFF 不是万能药。加一层就多一个要部署、要看日志、挂了页面全挂的服务。痛点不在,就别加。

后端已经给了页面级接口:比如已经有 /api/page/home,用户、订单、优惠券后端自己拼好了。你再套一层 BFF,只是把请求原样转发一遍,纯属重复。
纯展示型小项目,一个接口就够:个人博客、落地页,就一个列表接口。前端直连后端,没有"拼三个接口"的成本,加 BFF 是给自己找运维。
团队没有 Node 运维能力:BFF 挂了,页面接口全挂。还不会部署、看日志、设告警时,先别进生产。可以从 Mock 练手(只在本地跑,不扛流量)。

判断标准就一条:前端是不是在为"拼数据"付出明显成本(慢、乱、重复)? 是,才值得加 BFF。

总结

BFF 是在前端和后端之间加一层"前端专属服务",解决聚合、裁剪、脱敏、跨域
核心实现 = Express + Promise.all 并行聚合 + 字段裁剪
生产级 BFF 还要有超时、降级、缓存、监控
用 Node 做 BFF,是前端低成本获得"写服务端代码"能力的最佳入口

Node 与开发:前端为什么要学 Node.js

Fri, 11 Sep 2026 09:00:00 +0800

很多前端同学对 Node.js 的第一反应是"那是后端的东西,跟我没关系"。但只要你用过 npm install、跑过 vite dev、配过 webpack,你其实已经在用 Node 了——只是没意识到。

这篇文章先解决"为什么学"的问题:Node 到底是什么、它和你每天的工作有什么关系。

Node.js 是什么:V8 上的 JS 运行时

一句话:Node.js 是让 JavaScript 脱离浏览器、在服务器上运行的运行时环境。

拆开看两个关键词:

关键词	含义
V8	谷歌开发的 JS 引擎,Chrome 里跑 JS 的就是它。Node 把它单独拿了出来
运行时(Runtime)	提供 JS 语法之外的能力:读文件、开网络服务、操作进程……

所以同一个 JS 语言,在浏览器里能用 document、window,在 Node 里能用 fs、http、process。语言没变,变的是平台给的"工具包"。

// 浏览器环境
console.log(window.innerWidth);

// Node 环境
const fs = require('fs');
const files = fs.readdirSync('/tmp');
console.log(files);

Webpack / Vite / npm 都跑在 Node 上

这是前端学 Node 最现实的理由:你每天都在用的工具链,本身就是 Node 程序。

npm install、pnpm install —— 包管理器是 Node 写的
vite dev、webpack build —— 构建工具跑在 Node 进程里
eslint、prettier、husky —— 代码检查、格式化、git 钩子全是 Node CLI
你的 package.json 里的 scripts,每个命令都是一个 Node 进程

这意味着:不懂 Node,你就只能"会用"这些工具,不能"改"它们。

举个例子,项目里常见的构建脚本:

// scripts/build.js —— 这也是 Node 代码
const { execSync } = require('child_process');
const env = process.env.NODE_ENV || 'production';

execSync(`vite build --mode ${env}`, { stdio: 'inherit' });
console.log('构建完成');

一旦你认识 Node 的 child_process、path、fs,你就能看懂、能修改、能自己写这类脚本。这就是从"配工具的人"变成"造工具的人"的分水岭。

BFF、SSR、Mock 都靠它

这三个词是前端进阶路上绕不开的,而它们的共同点是:都需要一个 Node 服务。

概念	它解决什么	为什么需要 Node
BFF(Backend For Frontend)	后端接口太"碎",前端要聚合、裁剪、适配	在 Node 层写一个中间服务,帮前端拼数据
SSR(服务端渲染)	SEO 差、首屏慢	用 Node 在服务端把 HTML 渲染好再发给浏览器
Mock(接口模拟)	后端没写好,前端没法联调	用 Node 起一个假接口服务,返回模拟数据

以后端接口为例,一个页面可能需要同时请求用户信息、订单列表、优惠券三个接口,再自己拼装。有了 BFF,前端只调一个接口,聚合逻辑放在 Node 层:

// BFF 伪代码:把三个接口聚合成一个
app.get('/api/page/home', async (req, res) => {
  const [user, orders, coupons] = await Promise.all([
    fetch('http://api.internal/user'),
    fetch('http://api.internal/orders'),
    fetch('http://api.internal/coupons'),
  ]);
  res.json({ user, orders, coupons });
});

通往前端全栈的桥

对前端来说,Node 是成本最低的全栈入口:

不需要学第二门语言,还是 JavaScript/TypeScript
心智模型跟浏览器端 JS 高度重合(异步、事件、模块)
学了就能立刻用回前端工作:写脚本、做构建、搭 Mock、配 CI

前端 → Node 脚本 → Node 服务 → 全栈,是一条平滑的渐进路线,而不是"从零转行后端"。

总结

Node 是 V8 上的 JS 运行时,让 JS 走出浏览器
前端工具链(Webpack/Vite/npm)本质都是 Node 程序,懂 Node 才能改工具
BFF、SSR、Mock 是前端进阶的三大场景,都建立在 Node 之上
它是前端转全栈的桥,而不是一条分岔路