資訊專欄INFORMATION COLUMN
摘要：服務端任需要進行校驗來達到數據的可靠性前端的路由可能在服務端并不存在等等這一系列重用性的問題。串行并行，大幅縮短請求時間。關于作者本人主頁本文部分圖片段落參考文章淘寶前后端分離實踐微信公眾號會不定期推送前端技術文章，歡迎關注
一、背景
書接上文，淺談前后端分離與實踐(一) 我們用mock服務器搭建起來了自己的前端數據模擬服務，前后端開發過程中只需定義好接口規范，便可以相互進行各自的開發任務。聯調的時候，按照之前定義的開發規范進行數據聯調便可以了。前后端的職能更加清晰：
| 后端 | 前端 |
|---|---|
| 提供數據 | 接收數據，返回數據 |
| 處理業務邏輯 | 處理渲染邏輯 |
| Server-side MVC架構 | Client-side MV* 架構 |
| 代碼跑在服務器上 | 代碼跑在瀏覽器上 |
這里分離干凈了，分工也很明確了，看似一切都那么美好，but...我們也很容易發現問題的所在：
Client-side Model 是 Server-side Model 的加工
Client-side View 跟 Server-side是 不同層次的東西
Client-side的Controller 跟 Sever-side的Controller 各搞各的
Client-side的Route 但是 Server-side 可能沒有
也就是說服務端和客戶端各層職責重疊，大家各搞各的，很難統一具體要做的事情。并且可能會伴隨著一些性能上的問題。最具體的表現就是我們常用的SPA應用：
渲染，取值都在客戶端進行，有性能的問題
需要等待資源到齊才能進行，會有短暫白屏與閃動
在移動設備低速網路的體驗奇差無比
渲染都在客戶端，模版無法重用，SEO實現 麻煩
緊接著，我們代碼量越來越大，我們需要校驗的表單也會越來越多，有時候，前端提交需要校驗一次表單。
服務端任需要進行校驗來達到數據的可靠性；前端的路由可能在服務端并不存在....等等這一系列重用性的問題。所以我們之前的重構可能需要更深層次的思考。
在開始重構之前，我們需要對前后端界線做一個劃分，也就是說什么是屬于前端的范疇，什么是屬于后端的范疇，最傳統的前后端劃分可能是這樣的：
那么問題來了：我們前后端劃分的接線，是依照工作職責來劃分的前后端；還是依照硬體環境劃分的前后端？自從了nodejs之后，我們可以從工作職能上重新定義前后端的范疇：
可以看到，這里的前端比之前多了個nodejs，也就是在前后端之間我們構建了一個 nodejs 服務作為中間層！
為什么我們選擇的中間層是nodejs呢？因為我們把中間層歸在了前端的范疇，那么對前端小伙伴來說，nodejs畢竟還是個js，那么從語法角度來說，上收起來應該沒有什么問題。其次開發轉移成本也想對較低，不必來回切換語言的邏輯和語法：
前端熟悉的語言，學習成本低
都是JS，可以前后端復用
體質適合：事件驅動、非阻塞I/O
適合IO密集型業務
執行速度也不差
好了，提前說了這么多東西，那么這個中間層能給我們帶來什么了？要知道引入nodejs的開發成本也是很大的，首先就是多了一層服務，多的不說，單憑傳輸時間，就多了一層的傳輸時間啊！下面我們來研究一下什么應用場景下的nodejs能給我們帶來利大于弊的東西。
三、開始中間層之旅引入nodejs之后，我們來重新劃分一下前后端的職能：
這個就是中間層nodejs的主要思路，下面我們來看一下常見的業務場景：
1. 接口數據可靠性修復有的時候服務端返回給我們的數據可能并不是前端想要的結構，所有用到的展現數據都是后端通過異步接口(AJAX/JSONP)的方式提供的，前端只管展現。但是后端經常提供后端的數據邏輯，在前端還需要去處理這些數據邏輯。比如我再開發一個功能的時候，有時候會碰到這樣的問題：
服務端返回的某個字段為 null 或者服務端返回的數據結構太深，前端需要不斷寫這樣的代碼去判斷數據結構是否真的返回了正確的東西，而不是個null 或者undefined：
if (params.items && params.items.type && ...) {
// todo
}
對于這種情況，我們前端其實不應該去重復校驗數據的格式，這也本不應該是瀏覽器端js需要做的事情。我們可以在中間層做接口轉發，在轉發的過程中做數據處理。而不用擔心數據返回的問題：
router.get("/buyer/product/detail", (req, res, next) => {
httpRequest.get("/buyer/product/detail", (data) => {
// todo 處理數據
res.send(data);
})
})
2. 頁面性能優化 和 SEO
有點時候我們做單頁面應用，經常會碰到首屏加載性能問題，這個時候如果我們接了中間層nodejs的話，那么我們可以把首屏渲染的任務交給nodejs去做，次屏的渲染依然走之前的瀏覽器渲染。（前端換頁，瀏覽器端渲染，直接輸入網址，服務器渲染）服務端渲染對頁面進行拼接直出html字符串，可以大幅提高首屏渲染的時間，減少用戶的等待時間。這種形式應用最廣的比如 Vue 的服務端渲染，里面也有相關的介紹。
其次對于單頁面的SEO優化也是很好地處理方式，由于目前的ajax并不被搜索百度等搜索引擎支持，所以如果想要得到爬蟲的支持，那么服務端渲染也是一種解決方法。（PS：如果覺得服務端渲染太麻煩，我這里還有一篇介紹處理SEO的另一種思路處理 Vue 單頁面 Meta SEO的另一種思路可以參考）
需求：在淘寶，單日四億PV，頁面數據來自各個不同接口，為了不影響體驗，先產生頁面框架后，在發起多個異步請求取數據更新頁面，這些多出來的請求帶來的影響不小，尤其在無線端。
解決方案：在NodeJS端使用 Bigpiper 技術，合并請求，降低負擔，分批輸出，不影響體驗。同時可以拆分大接口為獨立小接口，并發請求。串行 => 并行，大幅縮短請求時間。
4. 更多可能 結語這里只是提供問題的一種解決思路，還是那句話：一切看應用場景。如果你對本文內容有別的意見也歡迎一起交流探討。
作者：monkeyWang
本人主頁：monkeyWang
本文部分圖片段落參考文章： 淘寶前后端分離實踐
微信公眾號：會不定期推送前端技術文章，歡迎關注
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/51420.html
摘要：服務端任需要進行校驗來達到數據的可靠性前端的路由可能在服務端并不存在等等這一系列重用性的問題。串行并行，大幅縮短請求時間。關于作者本人主頁本文部分圖片段落參考文章淘寶前后端分離實踐微信公眾號會不定期推送前端技術文章，歡迎關注 一、背景 書接上文，淺談前后端分離與實踐(一) 我們用mock服務器搭建起來了自己的前端數據模擬服務，前后端開發過程中只需定義好接口規范，便可以相互進行各自的開發...
摘要：前后端的界限是按照瀏覽器和服務器的劃分。前后端彼此互不關聯。關于作者本文部分圖片段落參考文章實踐中的前后端分離。淘寶前后端分離實踐本文源碼詳見服務端代碼。 一、起源 （故事純屬虛構，如有雷同，純屬巧合）傳說在很久很久以前，我們有志之士有了個創業的想法，于是乎開始了自己的創業之夢，但是人手不足啊，于是乎所有角色老子一個人全包了： Roles: PM, DBA, RD, FED, Des...
摘要：前后端的界限是按照瀏覽器和服務器的劃分。前后端彼此互不關聯。關于作者本文部分圖片段落參考文章實踐中的前后端分離。淘寶前后端分離實踐本文源碼詳見服務端代碼。 一、起源 （故事純屬虛構，如有雷同，純屬巧合）傳說在很久很久以前，我們有志之士有了個創業的想法，于是乎開始了自己的創業之夢，但是人手不足啊，于是乎所有角色老子一個人全包了： Roles: PM, DBA, RD, FED, Des...
摘要：延伸這里再順便提一下，新架構下的防御。不過，還有一點值得一提前后端分離框架下，路由由控制我自己要獲取的后端參數和需要用在業務邏輯的參數，在主觀上前端同學更好把握一些。 原文： http://feclub.cn/post/content... 背景 1、什么是CSRF攻擊？ 這里不再介紹CSRF，已經了解CSRF原理的同學可以直接跳到：3、前后端分離下有何不同？。 不太了解的同學可以看這...
閱讀 1534·2023-04-26 02:50
閱讀 3535·2023-04-26 00:28
閱讀 1931·2023-04-25 15:18
閱讀 3209·2021-11-24 10:31
閱讀 986·2019-08-30 13:00
閱讀 1000·2019-08-29 15:19
閱讀 1766·2019-08-29 13:09
閱讀 2975·2019-08-29 13:06
