再谈前后端分离
前段時間我針對手頭上的項目前端配置進行了反思以及總結并且寫了兩篇文章: 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, 知乎點贊之類的操作都是框架進行處理的.
其實蠻建議掘金也這樣處理得, 掘金網頁端訪問并不是很爽.
總結
上面不涉及具體代碼以及配置, 但是思路在那里, 不管后端是什么, 我們前端可以都寫的很爽, 同樣, 前后端分離不是說什么都是給前端干, 完全可以協調工作量.
最后有問題可以加群討論以及歡迎關注我的公眾號:
總結
- 上一篇： 面向 Web 前端的原生语言总结手册
- 下一篇： 基于React的表单开发的分析(上)