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

陽原網站制作公司哪家好，找創(chuàng)新互聯(lián)！從網頁設計、網站建設、微信開發(fā)、APP開發(fā)、成都響應式網站建設公司等網站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)從2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經驗和運維經驗，來保證我們的工作的順利進行。專注于網站建設就選創(chuàng)新互聯(lián)。

為什么要前后端分離

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

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

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

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

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

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

發(fā)起請求：

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

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!')
});

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

為什么需要中間層？

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

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

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

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

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

前輩們提出的解決方案

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

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

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

關于MVC的定義：

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

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

如：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 可能沒有

性能問題

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

重用問題

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

跨終端問題

• 業(yè)務太靠前，導致不同端重復實現(xiàn)
• 邏輯太靠前，造成維護上的不易

渲染都在客戶端，模版無法重用，SEO實現(xiàn) 麻煩

NodeJS作為中間層的全棧開發(fā)方案

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

我們使用Node層：

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

其實更為重要的是，對于前端來說，NodeJS的學習成本是相當?shù)偷模何覀儫o需學習一門新的語言，就能做到以前開發(fā)幫我們做的事情，一切都顯得那么自然。

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

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持創(chuàng)新互聯(lián)。