再談先後端分離

前段時間我針對手頭上的項目前端配置進行了反思以及總結而且寫了兩篇文章: webpack傳統後端渲染的項目前端配置, webpack配置以前後端不分離, 很顯然這些配置能知足一時的需求, 可是也有不足. 今天繼續總結, 這裏應該不涉及到具體後端語言, 只對前端配置進行描述. 畢竟配置工程師(逃

靜態資源管理

傳統後端主導的項目中對靜態資源不多處理, 畢竟後端主要仍是處理業務邏輯, 可是這樣一來前端的命門就被後端抓在手裏並且還不受重視, 這就致使這麼一個狀況: 前端寫好靜態頁面和css js扔給後端轉換爲jsp之類的後端模板. 更大的問題是後端會在頁面中增長不少後端邏輯. 這就弊處. 後端看在頁面寫一段java代碼處理邏輯方便那就很天然的這樣幹了. 後端寫完邏輯後前端發現本身看不懂了(這裏就須要稍微懂一點後端了), 這裏不能說誰錯了, 只是開發模式很不合理. 咱們須要作的是儘可能避免這種狀況的出現.

對於後端模板咱們姑且不算靜態資源. 那麼傳統後端對靜態資源的處理方式就以下圖所示:

很明顯, 靜態資源的處理都在後端. 可是靜態資源的無論呈現仍是處理都應該是前端的事情. 甚至極端狀況下html文件也應該是前端的事情, 因此spa(單頁應用)誕生了:

後端再也不直接參與前端邏輯和靜態資源的處理, 這樣固然有好處: 先後端算是徹底分離了, 頁面由前端渲染, 可是弊處也至關明顯: seo的問題, 首次加載速度... 等等. 再者前端沒法控制後端的接口質量, 致使分工卻是分了, 可是項目進度反而是慢了, 老項目也不可能進行徹底的分離, 我認爲操做性很強的web應用(注意是應用)徹底能夠直接spa, 好處也毋庸置疑. 可是對於一些展現性的網站, 好比知乎, 簡書等卻不必定非得這樣(知乎的問題後面會提到, 不徹底是react).

對於上面的狀況, 咱們可能有個更好的開發模式, 也是我目前在用的, 以下圖所示:

看起來彷佛第二個沒有明顯不同. 可是咱們要知道, 對於不少列表展現類的網頁可能後端渲染很方便不少, 對於單頁應用來講多入口的webpack配置多是不經常使用的. 可是若是是後端渲染的網頁, 每一個模板咱們都須要提供一個接口: 就是以前我寫的文章, 有興趣能夠回頭看看. 後端經過讀取資源表來獲取靜態資源, 也就是說後端基本不須要跟靜態資源打交道了. 更有趣的是咱們能夠在任意頁面引用任意框架, 對於某個操做性很強的頁面來講, 咱們徹底可使用vue, react ng等. 或者使用某個組件.

關於seo

其實seo我也不瞭解, 可是姑妄說之. 咱們首先來看兩個網站: 掘金和知乎, 在baidu和google下的搜索表現:

知乎在google:

掘金在google:

知乎在baidu:

掘金在baidu:

上面咱們能夠看到, 兩者其實仍是有點差距的吧, 固然也有多是掘金沒太關注這方面.

可是經過開發者工具其實咱們能夠看到兩者分別用了react和vue, 那麼兩者差別到底在哪呢? 咱們分別禁用兩個網站的js(此處無圖), 掘金一片空白, 知乎至少能夠正常渲染.

掘金徹底是前端渲染, 知乎作到這一點也很簡單就是後端渲染一遍前端再渲染一遍(貌似是多餘的), 可是我認爲這是值得的, 後端不須要寫接口, 把須要渲染的數據做爲INITIAL_STATE 賦值給window, 知乎點贊之類的操做都是框架進行處理的.

其實蠻建議掘金也這樣處理得, 掘金網頁端訪問並非很爽.

總結

上面不涉及具體代碼以及配置, 可是思路在那裏, 無論後端是什麼, 咱們前端能夠都寫的很爽, 一樣, 先後端分離不是說什麼都是給前端幹, 徹底能夠協調工做量.

最後有問題能夠加羣討論以及歡迎關注個人公衆號: