前後端分離的意義

嘗試與改變

如果你沒有嘗試過前後端分離的工作流程，那麼可以先試想一下這樣的流程改變：

把流程從 
PM：“我要這個功能”
後端：“這個先找前端做個模板”
前端：“模板做完了”
後端：“我來對接一下，這裏樣式不對”
前端：“我改完了”
後端：“功能交付”
PM：“春節要加這個活動”
後端：“這個先找前端改個模板”
前端：“模板做完了”
後端：“我來對接一下，這裏樣式不對”
前端：“我改完了”
後端：“功能交付”

變成
PM：“我要這個功能”
前端：“我要接口”
後端：“接口完成了”
前端：“我來對接一下，功能交付”
PM：“春節要加這個活動”
前端：“需要增加接口”
後端：“接口完成了”
前端：“我來對接一下，功能交付”

由此可見，前後端分離的主要概念就是：後臺只需提供API接口，前端調用AJAX實現數據呈現。

 

現狀與分歧

作爲一名前端開發人員，我們應該嘗試一些新穎的技術，完善每一個細節性的問題，不斷突破自我。雖然前後端分離已經算不上什麼新穎的技術或思路，但是目前很多後臺開發人員甚至前端開發人員都沒有接觸過。

據我個人的瞭解，如果在一個部門裏，部門人員全是後臺開發人員，前端的一些頁面也是由後臺人員完成的，那麼前後端分離對於他們而言可能是一片未知的領域，項目大多是前後端強耦合的，甚至不存在前端的概念。

在不重視前端的公司或部門，不瞭解前後端分離這也無可厚非。在我剛進入一個全是後臺開發人員的部門的時候，整個部門就我一個前端，我剛開始的主要職責就是負責項目前端頁面的製作和JS功能的實現，雖然部門有前後端分離的意識，但都不知該如何去實踐。在那時，部門的後臺人員認爲前後端分離就是後臺不再需要寫HTML和JS了，可以交給前端來做了，然而這隻能叫做前後端分工。

以上講述的是一種情況: 不瞭解前後端分離，也不知如何去實踐的。下面還有一種情況：瞭解前後端分離，但不想去嘗試的。

針對第二種情況，很多人也做過相應的解釋，其實這就涉及到“前後端分離的利弊”問題。很多後臺人員會認爲自己所做的那一套沒有問題，即便後臺套用前端html也是司空見慣，一直是大勢所趨，後臺MVC框架也是這麼推薦使用的，很合理。這時候前端開發人員在部門中的話語權往往是不夠的，或者認爲後臺開發人員的意見永遠是對的，沒有主觀性。

相反，也有可能是後臺開發人員非常推薦前後端分離，而前端開發人員不想去實踐的。這時候前端會認爲後臺開發人員在瞎折騰，之前前後端不分離項目做起來都很順利，分離了反而會給自己帶來額外的工作量和學習成本，而這就取決於前端的技術能力和見識了。

當然，這也是我個人認爲的前後端分離所存在的一些現狀和分歧所在。

 

場景與要求

對於前後端分離的應用場景，不是所有的場景都適合，但是大多數項目都能夠通過前後端分離來實現。

由於我主要從事企業級後臺應用的前端開發工作，個人認爲對於後臺應用的開發來說，前後端分離帶來的利是遠大於弊的。

大多數後臺應用我們都可以做成SPA應用（單頁應用），而單頁應用最主要的特點就是局部刷新，這通過前端控制路由調用AJAX，後臺提供接口便可以實現，而且這樣的方式用戶體驗更加友好，網頁加載更加快速，開發和維護成本也降低了不少，效率明顯提升。

同樣的，在展示類網站和移動APP頁面中前後端分離也同樣試用。前後端不分離的情況下，服務端要單獨針對Web端做處理，返回完整HTML，這樣勢必增加服務端的複雜度，可維護性差，而web端需要加載完整的HTML，一定程度上影響網頁性能，這對於移動端性能爲王的地方非常的不友好。

隨着前端技術的發展和迭代，前端MVC框架應運而生，利用目前主流的前端框架，如React、Vue、Angular等我們可以輕鬆的構建起一個無需服務器端渲染就可以展示的網站，同時這類框架都提供了前端路由功能，後臺可以不再控制路由的跳轉，將原本屬於前端的業務邏輯全部丟給前端，這樣前後端分離可以說是最爲徹底。下面是一段前端控制路由的代碼：

'use strict'

export default function (router) {
    router.map({
        '/': {
            component: function (resolve) {
                require(['./PC.vue'], resolve)
            }
        },
        '/m/:params': {
            component: function (resolve) {
                require(['./Mobile.vue'], resolve)
            }
        },
        '/p': {
            component: function (resolve) {
                require(['./PC.vue'], resolve)
            },
            subRoutes: {
                '/process/:username': {
                    component: function (resolve) {
                        require(['./components/Process.vue'], resolve)
                    }
                }
            }
        }
    })
}

前後端分離的實現對技術人員尤其是前端人員的要求會上升一個層次，前端的工作不只是切頁面寫模板或是處理一些簡單的js邏輯，前端需要處理服務器返回的各種數據格式，還需要掌握一系列的數據處理邏輯、MVC思想和各種主流框架。

 

優勢與意義

對於前後端分離的意義我們也可以看做是前端渲染的意義，我主要總結了下面四點：

1.徹底解放前端

前端不再需要向後臺提供模板或是後臺在前端html中嵌入後臺代碼，如：

<!--服務器端渲染 -->
<select>
    <option value=''>--請選擇所屬業務--</option>
    {% for p in p_list %}
    <option value="{{ p }}">{{ p }}</option>
    {% endfor %}
</select>

這是前後端耦合的，可讀性差。

<!--前端渲染 -->
<template>
    <select id="rander">
        <option value=''>--請選擇所屬業務--</option>
        <option v-for="list in lists" :value="list" v-text="list"></option>
    </select>
</template>

<script>
export default {
    data: {
        return {
            lists: ['選項一', '選項二', '選項三', '選項四']
        }
    }，
    ready: function () {
        this.$http({
            url: '/demo/',
            method: 'POST',
        })
        .then(function (response) {
            this.lists = response.data.lists // 獲取服務器端數據並渲染
        })
    }
}
</script>

上面是前端渲染的一段代碼，前端通過AJAX調用後臺接口，數據邏輯放在前端，由前端維護。

2.提高工作效率，分工更加明確

前後端分離的工作流程可以使前端只關注前端的事，後臺只關心後臺的活，兩者開發可以同時進行，在後臺還沒有時間提供接口的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩後臺，開發更加靈活。

3.局部性能提升

通過前端路由的配置，我們可以實現頁面的按需加載，無需一開始加載首頁便加載網站的所有的資源，服務器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。

4.降低維護成本

通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後臺人員參與及調試，代碼重構及可維護性增強。

 

心得與體會

一路走來，項目一個接着一個，從一開始的後臺控制路由、後臺渲染頁面到現在的前端控制路由、前端渲染數據，工作流程和方式都發生了很大的變化。每當遇到下面情形的時候，我都會爲前後端分離帶來的優勢而感慨一番：

• 項目一開始製作前端頁面的時候，我不再需要後臺給我配置服務器環境了

• 項目的前端文件可以在需要調用後臺接口的時候丟進服務器就好了，完全不需要事先放進去

• 增加一個項目頁面需要配置路由的時候不再需要讓後臺同事給我加了，自己前端搞定

• 前端文件裏不再摻雜後臺的代碼邏輯了，看起來舒服多了

• 頁面跳轉比之前更加流暢了，局部渲染局部加載非常快速

• 頁面模板可以重複使用了，前端組件化開發提高了開發效率

等等。面對快速發展的前端，我們應該去適應其帶來的工作方式和流程的改變，目前的前後端分離的工作方式必然是今後的趨勢所在，作爲一個前端開發人員，我們應當承擔這個普及前端新知識和改變現狀的職責。

 

只有嘗試了才知道適不適合，只有切身體會才能辨別誰是誰非，本文並非推崇一定要前後端分離，而是希望大家在合適的應用場景下去嘗試前後端分離，在豐富經驗的同時或許也會擦出火花。

本文轉載來自一個蘿蔔一個坑 -博客園[http://www.cnblogs.com/luozhihao]