《從零構建先後分離web項目》探究 - 深刻聊聊先後分離架構

時間 2019-11-11

原文原文鏈接

探究：深刻聊聊先後分離架構

先後分離，一直是一個至關泛泛的問題，先後分離到底好很差？沒有絕對的對，沒有絕對的錯，業界就這個問題已經激烈的探討幾年了.出現討論的點在於：分離固然是好的,可是以什麼樣的服務須要進行先後拆分？拆分到什麼粒度？先後端如何配合？
html

截圖時間: 2018-08-30 - Github

咱們隨意在 Github 輸入先後分離關鍵字，看下搜索的結果: 1K 的庫 11k 的 Issues 足以說明先後分離的趨勢，能夠想象激烈程度，業界比較有名的討論：Web 先後端分離的意義大嗎？，值得一提的是：前排對於這個問題討論比較深入的大部分都是全棧工程師。由於全棧對全局的瞭解相對比單純作前端、後端全局觀念更強一些，考慮的問題更多一些。前端

篩簡歷引起的思考和分析

後端職位的怪圈

在公司的簡歷庫隨手截幾個局部的圖，近兩年面試過不少的 1-3 年 java 開發者，在篩選簡歷和麪試過程當中，也發現了幾個問題：至關多一部分 javaer 技術棧上老是多了那麼個 HTML ajax jquery bootstrap easyUi ，看起來很唐突，若是面試提到了前端技術棧，基本沒有能答的很好的，甚至有的人連 原型鏈 都不知道。這也是大部分人對全棧的誤解，其實我是不太感冒這樣的簡歷的，由於沒有什麼亮點，技術棧不是寫的越多越好，總結起來：他們對前端的掌握很基礎，勉強能勝任一些業務上的工做。那爲何這麼多人都掌握一些前端技術呢？我分析可能有三點：vue

思考緣由：

培訓機構的興起，機械化的教學
求職者自身的興趣
一些公司的技術棧不全，對技術沒有追求，大部分用的幾年前的架構，先後業務耦合很大，市場缺口大

分析

由於我也維護過幾個月的敏感項目，深有體會，只寫服務端的人是沒法勝任這項工做的，
若是多數的開發者這樣的簡歷，能夠推測：如今的 IT 行業中先後端糅雜一塊兒的架構仍是存在、而且有一個量級，這致使他們不得不尋找一些懂得一點前端技術的人來開發項目，減小溝通的成本，加快項目的進度，這也就催生了不少所謂的 web 開發培訓機構。java

你問我當年維護的開心嗎？一會告訴你。

什麼是先後分離

先後端分離並非什麼新鮮事，處處都是先後端分離的實踐。然而一些歷史項目在從一體化 Web 設計轉向先後端分離的架構時，不可避免的會遇到各類各樣的問題。因爲層出不窮的問題，甚至會有團隊質疑，一體化好好的，爲何要搞先後端分離？說到底，仍是技術和思惟方式沒轉變過來。node

一體化模式其實在上一開篇：縱觀歷史演變中已經提到過了，不在贅述。jquery

先後分離看起來應該是這樣的：webpack

先後分離就是在架構層次上構建項目或對現有的項目 客戶端 服務端 分離開，減小先後端代碼的耦合度，你們一致認同的先後端分離的例子就是SPA(Single-page application) ，全部用到的展示數據都是後端經過 JSON 但不只限於 JSON 的方式提供的，前端只管展示,提供更好更絢的交互，後端只管提供更健壯的高可用服務。ios

千萬不要有先寫項目，寫完再重構的想法，項目初期能一步到位最好，何須再去重構，而後不得已拋棄一些已經寫完的組件、庫浪費人力呢？nginx

先後分離解決了什麼問題

每一個人各盡其職

好的開發者是可與不可求的，若尋找一個 優秀的 full_stack 更是難，從校招進行培養也不太實際，招一個能力通常的程序員，技術驅動性比較差，甚至拖慢產品迭代。分離開來咱們就能夠專一於前端、 服務端 領域去尋找專業的人才。git

解耦

前端後端代碼大量耦合代碼看起來是這樣的：

看看簡單例子吧：

//(node端處理)
if (is_weixin()) {
init([
'api',
'image',
'xxx',
'...',
], function () {
<%- doSomeGloble %>
});
} else {

}
//接收node端一些數據
let blogs = <%- blogs %>;

let users = <%- users %>;

這還不是 JAVA 模板而是相對輕量、優雅的 NODE 的 EJS 渲染的，這還好，我見過更使人難受的代碼，常常爲了一個問題要回頭看 N 多代碼，這裏就不寫了。

那麼先後分離如何讓它們解耦變得更清晰？後面會結合服務端統一補充。

什麼項目不適合先後分離

blog、文檔

你說你搭建一個博客、 API 文檔系統 這種小項目，一我的就能夠開發。搞了一個先後分離，須要分離部署。又增長了 SEO 的複雜度，增長了開發的週期、增長了用戶部署的難度，何須呢？固然，若是隻是技術實踐的一種學習方式，仍是歡迎的。

先後分離帶來的問題，如何解決？

溝通成本問題

前端妹子：哥，獲取所有博客調哪一個接口？
哦，昨天不是發你文件了嗎

前端妹子：我找不到了😭

哦，等下吃晚飯發你啊

前端妹子：哥，產品提出根據手機殼自動換主題的需求，你有接口嗎？
... 我看看...應該...沒有！可能須要 Python 的老哥支持！你去找他要吧

前端妹子：哥，你根據 TAG 獲取博客的接口寫完了沒？接口是啥？我好渲染數據啊
沒等等......

這顯然是不規範的，咱們指望的是前端後端先約定一個接口協議，後端沒完成時，前端本身 mock 測試數據，前端找不到接口的時候，直接查看 API ，根據這個接口協議咱們先後端統一編程，那麼咱們如何處理呢？

如何下降溝通成本？
後端數據服務化，走統一的 REST 接口規範輸出，下降先後端接口定義的溝通成本。避免「口頭說明」的方式。

什麼是 RESTful API ？
因此RESTful API就是REST風格的API。那麼在什麼場景下使用RESTful API呢？在當今的互聯網應用的前端展現媒介很豐富。有手機、有平板電腦還有PC以及其餘的展現媒介。那麼這些前端接收到的用戶請求統一由一個後臺來處理並返回給不一樣的前端確定是最科學和最經濟的方式，RESTful API就是一套協議來規範多種形式的前端和同一個後臺的交互方式。

我一般用 swagger + mock 平臺生成標準的 RESTful API，同時也支持擴展多個編程語言例如： Go Python

SEO 問題

以 vue + webpack 的 SPA 爲例，沒有了後端模板返回的 HTML，前端渲染並不被搜索引擎的爬蟲接納。在往後實戰 SEO 以前先通俗渲染唄爬蟲識別的區別：

seo 本質是一個服務器向另外一個服務器發起請求，解析請求內容。但通常來講搜索引擎是不回去執行請求到的 js 的。也就是說，若是一個單頁應用，html 在服務器端尚未渲染部分數據數據，在瀏覽器才渲染出數據，而搜索引擎請求到的 html 是沒有渲染數據的。這樣就很不利於內容被搜索引擎搜索到。因此服務端渲染就是儘可能在服務器發送到瀏覽器前頁面上就是有數據的。

以博客爲例簡單聊聊:

靜態服務

<div>我是正文1</div>
<div>我是正文2</div>
<div>我是正文3</div>

爬蟲直接抓到 html 解析 - 生成索引

傳統後端渲染

@RequestMapping("/index") 
    public String index(HttpServletRequest request,HttpServletResponse   response){ 
        return "welcome"; 
    }

這裏就比較有意思了，好比咱們打開的網址是:

http://host:port/index
實際充當 Controller 的是服務端，服務端直接返回渲染好的網頁給你，爬蟲拿到的也是同樣，因此 SEO 沒啥太大的問題。

先後分離 SPA

let blogs = [];

this.axios.get('/index, {})
                .then(res => {
                 blogs = res.data;    
                })
                .catch(err => {
                    console.error(err);
                });
                
             <!--前端模板渲染dom-->   
 <div  v-for="(item, index) in blogs" :key="item">

一樣咱們輸入
http://host:port/index