快捷導(dǎo)航

詳解從NodeJS搭建中間層再談前后端分離

更新時間：2018年11月13日 09:29:27 作者：mountain_tea

這篇文章主要介紹了詳解從NodeJS搭建中間層再談前后端分離，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

之前在知道創(chuàng)宇的項(xiàng)目中有用到過nodejs作中間層，當(dāng)時還不太理解其背后真正的原因；后來在和一位學(xué)長交談的過程中，也了解到螞蟻金服也在使用類似的方法，使用nodejs作為中間層去請求真實(shí)后臺的數(shù)據(jù)；之后人到北京，也見到現(xiàn)在的公司也在往nodejs后端方向靠攏。隨著知識的增加，加之自己查閱資料，慢慢總結(jié)出了一些原理。

為什么要前后端分離

1、開發(fā)效率高
前端開發(fā)人員不用苦苦地配置各種后端環(huán)境，安裝各種莫名的插件，擺脫對后端開發(fā)環(huán)境的依賴，一門心思寫前端代碼就好，后端開發(fā)人員也不用時不時的跑去幫著前端配環(huán)境。

2、職責(zé)清晰，找bug方便
以前有了bug，前端推后端，后端推前端，不知道該誰去該，前后端分離，是誰的問題就該誰去處理，處理問題方便很多，后期代碼重構(gòu)方便，做到了高可維護(hù)性。

從做微信小程序引發(fā)的思考

最近出于愛好，寫了個音樂播放器的微信小程序（原本想用vue寫的，后來因?yàn)楣緲I(yè)務(wù)原因，年后可能去做微信小程序，所以就換了前端技術(shù)棧），源碼在我的GitHub上： wx-audio 。

思考：后端出于性能和別的原因，提供的接口所返回的數(shù)據(jù)格式也許不太適合前端直接使用，前端所需的排序功能、篩選功能，以及到了視圖層的頁面展現(xiàn)，也許都需要對接口所提供的數(shù)據(jù)進(jìn)行二次處理。這些處理雖可以放在前端來進(jìn)行，但也許數(shù)據(jù)量一大便會浪費(fèi)瀏覽器性能。因而現(xiàn)今，增加node端便是一種良好的解決方案。

在我的微信小程序demo的server端代碼中，我通過http模塊對真實(shí)后臺（網(wǎng)易云音樂API）發(fā)起http請求，然后通過express模塊搭建后端服務(wù)。

發(fā)起請求：

// http.js
var formatURL = require('./formatURL.js');
var http = require('http');
const POSThttp = function(request){
 return new Promise((resolve, reject) => {
  let body = '';
  // http模塊拿到真實(shí)后臺api的數(shù)據(jù)
  http.get(formatURL(request.body.musicname), function(res){
   res.on('data', (data) => {
    body += data;
   }).on('end', () => {
    // 格式化
    const {
     name,
     audio: musicUrl,
     page,
     album: {
      name: musicName,
      picUrl,
     },
     artists: [{
      name: singer,
     }],
    } = JSON.parse(body).result.songs[0];
    const reply = {
     name,
     picUrl,
     musicUrl,
     page,
     singer,
    };
    resolve(reply);
   });
  });
 });
};
module.exports = POSThttp;

得到數(shù)據(jù)傳回前端：

var express = require('express');
var POSThttp = require('./POSThttp.js');
var bodyParser = require('body-parser');
// 使用body-parser解析post請求的參數(shù)，如果沒有，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!')
});

這幾十行代碼也就實(shí)現(xiàn)了一個簡單的中間層的demo，并做到了在中間層格式化參數(shù)，便于前端進(jìn)行使用的過程。

為什么需要中間層？

其實(shí)這個問題，我認(rèn)為跟面試?？嫉念}：“為什么需要前后端分離？”是類似的，其原因可以歸納為以下幾點(diǎn)：

現(xiàn)今網(wǎng)站存在問題

之前有向一位在百度有多年工作經(jīng)驗(yàn)的老前輩交談這類問題，我所提到的搜狐公司代碼冗余、前后端耦合的問題，他是這么回答并且給予我這樣的建議：

其實(shí)，提煉出來，現(xiàn)今大公司的老項(xiàng)目（包括百度、搜狐等公司所采用的后端渲染等），或多或少都會存在這樣的一些問題：

前端代碼越來越復(fù)雜
前后端依舊高度耦合
無法良好的支持跨終端

前輩們提出的解決方案

參考淘寶前后端分離解決方案

前端代碼越來越復(fù)雜，我們希望盡可能地減少工作量，開始使用類似MV*的分層結(jié)構(gòu)，使前端后分離成為必要。
前端需要處理更多的工作，希望有權(quán)操控View，Router（如：SPA的嘗試）
各種終端設(shè)備的興起，需要我們把頁面適配到更多的地方。

開始：我們所嘗試的CLIENT-SIDE MV* 框架，后端暴露數(shù)據(jù)接口、處理業(yè)務(wù)邏輯，前端接收數(shù)據(jù)、處理渲染邏輯。

關(guān)于MVC的定義：

MVC是一種設(shè)計模式，它將應(yīng)用劃分為3個部分：數(shù)據(jù)（模型）、展現(xiàn)層（視圖）和用戶交互（控制器）。換句話說，一個事件的發(fā)生是這樣的過程：
　　1. 用戶和應(yīng)用產(chǎn)生交互。
　　2. 控制器的事件處理器被觸發(fā)。
　　3. 控制器從模型中請求數(shù)據(jù)，并將其交給視圖。
　　4. 視圖將數(shù)據(jù)呈現(xiàn)給用戶。

我們不用類庫或框架就可以實(shí)現(xiàn)這種MVC架構(gòu)模式。關(guān)鍵是要將MVC的每部分按照職責(zé)進(jìn)行劃分，將代碼清晰地分割為若干部分，并保持良好的解耦。這樣可以對每個部分進(jìn)行獨(dú)立開發(fā)、測試和維護(hù)。

如：Backbone, EmberJS, KnockoutJS, AngularJS等框架。

但這樣的方式仍舊存在問題：

各層職責(zé)重疊