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

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

為什么要前后端分離

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

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

從做微信小程序引發的思考

最近出于愛好，寫了個音樂播放器的微信小程序（原本想用vue寫的，后來因為公司業務原因，年后可能去做微信小程序，所以就換了前端技術棧），源碼在我的GitHub上： wx-audio 。

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

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

發起請求：

// http.js
var formatURL = require('./formatURL.js');
var http = require('http');
const POSThttp = function(request){
 return new Promise((resolve, reject) => {
  let body = '';
  // http模塊拿到真實后臺api的數據
  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;

得到數據傳回前端：

var express = require('express');
var POSThttp = require('./POSThttp.js');
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 各搞各的
• Client-side的Route 但是 Server-side 可能沒有

性能問題

• 渲染，取值都在客戶端進行，有性能的問題
• 需要等待資源到齊才能進行，會有短暫白屏與閃動
• 在移動設備低速網路的體驗奇差無比

重用問題

• 模版無法重用，造成維護上的麻煩與不一致
• 邏輯無法重用，前端的校驗后端仍須在做一次
• 路由無法重用，前端的路由在后端未必存在

跨終端問題

• 業務太靠前，導致不同端重復實現
• 邏輯太靠前，造成維護上的不易

渲染都在客戶端，模版無法重用，SEO實現 麻煩

NodeJS作為中間層的全棧開發方案

有了NodeJS之后，前端可以更加專注于視圖層，而讓更多的數據邏輯放在Node層處理。

我們使用Node層：

• 轉發數據，串接服務
• 路由設計，控制邏輯
• 渲染頁面，體驗優化
• 中間層帶來的性能問題，在異步ajax轉成同步渲染過程中得到平衡
• 更多的可能

其實更為重要的是，對于前端來說，NodeJS的學習成本是相當低的：我們無需學習一門新的語言，就能做到以前開發幫我們做的事情，一切都顯得那么自然。

技術在不斷變化中，唯有跟上技術革新的浪潮，才能不被時代所淘汰，不管是人還是企業。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持億速云。