var bodyParser = require('body-parser');
// 使用body-parser解析post请求的参数，如果没有，req.body为undefined。
var app = express();
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({
extended: true
}));
app.post('/', (req, res) => {
POSThttp(req).then((data) => {
res.send(data);
}).catch((err) => {
res.send(err);
});
});
app.listen(3000, () => {
console.log('open wx-audio server successful!')
});
这几十行代码也就实现了一个简单的中间层的demo，并做到了在中间层格式化参数，便于前端进行使用的过程。
为什么需要中间层？
其实这个问题，我认为跟面试常考的题：“为什么需要前后端分离？”是类似的，其原因可以归纳为以下几点：
现今网站存在问题
之前有向一位在百度有多年工作经验的老前辈交谈这类问题，我所提到的搜狐公司代码冗余、前后端耦合的问题，他是这么回答并且给予我这样的建议：
其实，提炼出来，现今大公司的老项目（包括百度、搜狐等公司所采用的后端渲染等），或多或少都会存在这样的一些 问题 ：
前端代码越来越复杂
前后端依旧高度耦合
无法良好的支持跨终端
前辈们提出的解决方案
参考 淘宝前后端分离解决方案
前端代码越来越复杂，我们希望尽可能地减少工作量，开始使用类似MV*的分层结构，使前端后分离成为必要。
前端需要处理更多的工作，希望有权操控View，Router（如：SPA的尝试）
各种终端设备的兴起，需要我们把页面适配到更多的地方。
开始：我们所尝试的CLIENT-SIDE MV* 框架，后端暴露数据接口、处理业务逻辑，前端接收数据、处理渲染逻辑。
关于MVC的定义：
MVC是一种设计模式，它将应用划分为3个部分：数据（模型）、展现层（视图）和用户交互（控制器）。换句话说，一个事件的发生是这样的过程：
1. 用户和应用产生交互。
2. 控制器的事件处理器被触发。
3. 控制器从模型中请求数据，并将其交给视图。
4. 视图将数据呈现给用户。
我们不用类库或框架就可以实现这种MVC架构模式。关键是要将MVC的每部分按照职责进行划分，将代码清晰地分割为若干部分，并保持良好的解耦。这样可以对每个部分进行独立开发、测试和维护。
如：Backbone, EmberJS, KnockoutJS, AngularJS等框架。
但这样的方式仍旧存在问题：
各层职责重叠
Client-side Model 是 Server-side Model 的加工
Client-side View 跟 Server-side是 不同层次的东西
Client-side的Controller 跟 Sever-side的Controller 各搞各的
