目录：
一、什么是前后端分离？
大部分人认同开发微信小程序或SPA(WEB单页应用)是实现“前后端分离”的。所有业务数据都是“后端应用”通过HTTP接口提供给“前端应用”。一个“完整的应用”被物理隔离为两个独立的应用，并由擅长的开发者负责，从而实现职责分离：
前端开发者：负责 View 和 Controller 层。
后端开发者：只负责 Model 层，业务处理/数据等。
“前后端分离”是强调“职责分离”，上面应用分离的例子是为了方便理解接受，可以不应用分离。通常应用分离能大量减少不小心的越界行为。
前后端分离后的样子：
二、为什么要前后端分离？
根据上图，只有“web网站”和“React Isomorphic”两种形态应用没有自然物理隔离前端和后端。我们存在很多没有前后端分离的web网站应用（这也是痛苦的根源），而React Isomorphic应用是前后端分离流行后的开发模式（代替web网站应用）。
2.1 清晰前后端职责
分离前：前端开发者提供静态页面，后端开发者完成 Controller 和 View 层代码。但前端开发者经常会插一脚修改 Controller 和 View 层代码。
分离后：面向用户的 Controller 和 View 层都由前端开发者做；后端开发者只需复杂 Model 层，提供业务数据接口。
前后端分离后基本不需要相互修改对方代码。
2.2 提高开发效率
分离前：前端和后端沟通/约定页面模板的每个字段、字段值的格式、适合模板的数据结构。
分离后：前段和后端沟通需要的 Model 接口。
前后端分离能明显减少沟通成本；约定的内容也少很多，减少大量联调时间。
2.3 前端能做更多，后端能更专一
前端可以服务端开发，而且可以不再局限WEB开发，同一套API，前端可以实现SPA、微信小程序、支付宝小程序等。
后端能更专一API开发，不用为UI要求的时间格式、模板布局要求的数据结构发愁。
三、基于Node.js做前后端分离
目前存在很多web网站应用，我们正在用PHP实践前后端分离。前端同事对PHP不熟悉，成本比较高，所以最终会考虑使用Node.js实践前后端分离。
这里只讨论web网站和React Isomorphic应用，因为其他形态的应用已经物理分离了前后端。
React Isomorphic应用比web网站应用更“先进”，而且Node.js生态已有成熟的方案，所以新项目也会更倾向选择React Isomorphic应用。
3.1 为什么选择Node.js而不继续用PHP？
3.1.1 招聘成本
招会Node.js的前端比招会PHP的前端容易。
3.1.2 学习成本
前端学习PHP语言。语法学习成本不高，但熟悉度还是要时间成本的。
3.1.3 开发成本
开发过程频繁切换语言。经常会在PHP中写JS语法，这点比较烦。
3.1.4 服务器性能
在自己服务器测试两种场景。
服务器配置：
- 腾讯云服务器（Ubuntu 16.04.1 LTS）
- CPU: 2核
- 内存：4GB
- 带宽：2M
Node.js环境：
- Node.js版本：v8.12.0(Alinode v3.12.0)
- 框架：Egg.js
- worker进程数：2
PHP环境：
- PHP版本：7.2.10
- 框架：Lumen
- php-fpm最大子进程数：5
两种场景测试代码：
场景一，直接输出字符串，不做任何IO和计算。
PHP效率比Node.js高
Node.js:
// egg-4
async function test(ctx) {
ctx.body = '<h1>goddess.daifee.com</h1><p>Egg程序</p>';
}
PHP:
// php-4
$router->get('/test', function () use ($router) {
return '<h1>goddess-php.daifee.com</h1><p>这是PHP服务</p>';
});
场景二，模拟200ms的网络请求。
Node.js效率比PHP高。相对“场景一”PHP效率下降明显，Node.js不明显。
Node.js:
// egg-4—test2
async function test2(ctx) {
const start = Date.now();
await new Promise(resolve => {
setTimeout(() => {
resolve(true);
}, 200);
});
const offset = Date.now() - start;
ctx.body = `<h1>goddess.daifee.com</h1><p>Egg程序 ${offset}</p>`;
}
PHP:
// ./WeTest_[php-4—test2]_20181014172129.pdf
$router->get('/test2', function () use ($router) {
$start = microtime(true);
usleep(200000);
$offset = microtime(true) - $start;
return "<h1>goddess-php.daifee.com</h1><p>这是PHP服务 {$offset}</p>";
});
3.2 基于Egg.js框架开发（编码）
下面用Egg.js框架开发一个页面为例（浏览器端开发模式不需要改变）。
开发一个新页面（用户主页页），只需要下面4个步骤：
- 模板：创建模板文件。
<!-- app/views/user.ejs -->
这里是 ejs 模板
- 数据接口：几行代码封装数据接口。
// app/service/user.js
const { Service } = require('egg');
module.exports = class UserService extends Service {
async get(userId) {
const url = `https://api.gateway.com/xxx/${userId}`;
// http请求/ajax
const response = await this.app.curl(url);
return response;
}
}
- 控制器：过滤/验证用户输入、验证权限、调用数据接口、渲染模板。
// app/controller/user.js
const BaseController = require('./base-controller');
module.exports = class UserController extends BaseController {
async profile() {
const { params, service } = this.ctx;
// 只有自己才能访问自己主页。不是自己就抛出 403 异常
this.assertUser(params.userId);
user = await service.user.get(params.userId);
await this.render('user', {user: user});
}
}
- 路由：一行代码声明路由。
// app/router.js
module.exports = app => {
const { router, controller, middleware } = app;
const { authorize } = middleware;
const { user } = controller;
// 已登录用户才能访问
router.get('/users/:userId', authorize.user, user.profile);
}
只负责 Controller 和 View 层的Node.js服务端开发非常简单。一个企业应用除了开发，还有其他环节需要做好。
3.3 我们还缺什么？
前端开发者可以在服务端写 Controller 和 View 层代码，但整个生产环节还缺什么？
3.3.1 前端开发者
既然前端开发者需要做更多，能做更多，所以工作量增加。所以缺前端开发者。
- 同一个项目，编码的工作量增加了。
- 前端同事需要关注、分析、协助维护Node.js服务器。
- 肯定会有更多的xxx小程序需求。
3.3.2 适合我们的框架和项目脚手架
- 确定了web网站应用使用Egg框架，还需为不同业务场景的项目创建拿来即用的脚手架。
- 未确定React Isomorphic应用的框架。我体验过next.js，是一个不错的选择。
3.3.3 构建/部署服务
目前还没有Node.js项目的构建/部署服务。
基本需求：
- 构建：开发者只需关注源码，“构建服务”自动构建项目。
- 发布：支持选择git tag构建，部署到“生产环境”。
- 发布：支持选择git branch构建，部署到“测试环境”。
- 回滚：支持指定版本回滚。
- 重启：支持重启Node.js服务器。
- 发布：允许测试人员发布“测试版本”。
3.3.4 严谨的git工作流
需要依据“构建/部署服务”定制严谨的git工作流。
3.3.5 风险监控和日志采集
- 风险监控可以考虑Alinode。
- 完全免费
- 支持性能监控、安全提醒、故障排查、性能优化等
- 支持手动下载性能数据
- 日志采集接入大数据团队的服务？
关于React Isomrophic
当时用React全家桶做了一个SPA Demo项目，然后用next.js框架再做一个React Isomorphic版。发现可以复用（copy）98%的代码，然后花一点时间将 React Router 替换为 next.js 自带的 Router 即可
基于 next.js 框架 React Isomorphic 应用与 SPA 的开发体验差不多。
毕竟一套代码运行于两个不同环境，React Isomorphic 还是带来了一些坑：
- 需要意识到哪些代码在2个环境都执行，哪些代码只在其中一个环境执行。
- 立即执行的代码在2个环境都执行。
- React组件生命周期的代码只在Browser环境执行。
-
Component.getInitialProps()方法在2个环境都执行。 - 小心使用运行环境的“接口”
-
next.js自带Router，与“其他Router”肯定存在差异。 - 某些组件需要用唯一自增ID或随机数，这种做法会使服务端于客户端存在差异。
- “服务端”与“客户端”基本只能用cookie共享“状态”，要珍惜cookie资源。
