淺談前後端分離
之所以想聊聊前後端分離這個話題,是因為發現自己及身邊很多人對圍繞 前後端分離的h5、單頁應用和服務端渲染等概念理解不準確,對我來說,都不好意思說自己是web開發者,所以專門去了解和整理了相關的知識,以此分享給大家:
何為前後端分離?
隨著近幾年移動網際網路的興起,特別是前端領域的html5,CSS3,ECMAScript5和6(也就是javaScript語言的規範)的制定並被業界支援,前後端 分離這種技術架構越來越流行,筆者近3年 參與的實際專案,基本上都是 採用前後端分離的開發模式。
那麼,什麼是前後端分離呢?去網上一搜,答案挺多的,都沒有絕對的對錯,只是站在不同的角度去定義而已。我比較認可的定義如下:在技術架構上,前後端只通過Restful風格(最佳實踐)的API以JSON 資料格式(使用最多)進行互動,而不是組織或崗位的分離。
其實,要想講清前後端 分離這個概念,得回顧一下整個web開發的歷史,特別是js的歷史,在分工上,其實之前 也可以算是前後端分離,老一代的前端開發都不叫軟體工程師,大家愛稱切圖仔或妹,但在技術架構上,前後端的程式碼基本上是在一個工程裡,後端開發語言通過各種前端模板引擎(如淘寶的kissy template,騰訊的artTemplate,百度的baiduTemplate等) 來渲染前端頁面,或者是類似以Java語言為基礎的動態生成web頁面的jsp技術等,前後端在架構上緊密關聯的。
這就是大家常聽到的耦合,體現在 改一下前端頁面的展示,特別是涉及互動邏輯的,整個工程(前後端程式碼)往往都要一起重新發布上線一次,存在耗時長、不靈活、前後端溝通過多等不足,所以就慢慢有了 前後端 分離這種技術架構來 解耦,即前後端的程式碼在不同的專案工程,各自發布上線,降低相互間的聯絡。
舉個在搜狐真實專案的例子,我們客戶端有android, ios和h5三個平臺,業務為個人小額信用貸款,類似騰訊微信裡的微粒貸,後端基於Java開發,只提供restful 風格的API服務,android, ios和h5在一個專案工程(為快速驗證業務和降低成本,我們基於rective native 統一了客戶端,多數客戶端架構都是各端一個專案工程,技術棧也不一樣,比如目前我們做的系統Android基於java, ios基於oc, h5基於vue,pc 端基於自研的ecui),前後端通過json進行互動,當時為了讓系統更靈活和降低 前後端的複雜度,我們還加入了node中間層進行合併請求和格式化資料等。
為何需要前後端分離?
通過前一節,我們應該知道本節探討的,準確來講,應該是web開發 為什麼 會出現 前後端 分離 這種技術架構?顯然,技術 基本都是源於 業務發展的客觀需要,扯大了講 就是 馬克思談的 經濟學了。
作為技術,還是不吹了。。。移動網際網路時代,最明顯的改變就是智慧手機了,手機上的原生APP,以及在手機瀏覽器訪問的web app(圈內簡稱h5, 因為HTML5規範引入了很多移動端相關特性),各端 的互動不一樣,而且越來越複雜,傳統的MVC技術架構(如Java系統的 控制層 負責接收引數,呼叫相關 業務層,封裝 資料 以及通過路由 渲染 到jsp頁面)實現起來越來越吃力,甚至不可能了。
舉例來說,以前基於jsp的javaWeb專案沒有那麼苛刻的效能要求,但在大資料時代,對於web系統的效能要求越來越高,前後端耦合在一起的架構模式已經不能滿足大型web系統的需要,所以需要找一種解耦的方式,來大幅度提升系統的效能和靈活度。
而且,之前的UI出圖後,前端只負責將設計圖切成html,然後再由java工程師來將html套成jsp頁面的協作模式,出錯率較高;動態資源和靜態資源全部耦合在一起,伺服器壓力也大;還有jsp技術本身的效能,前端開發需要使用Java IDE並配置環境等,讓前後端都很痛苦。
其他基於PHP,甚至是基於node的MVC web系統,只要是前後端耦合的,在開發複雜web 應用時,都會存在類似的問題,所以最近幾年 前後端分離 的技術架構成了 很多架構師 設計系統時的首選,當然我們自己開發個部落格或者是小系統,使用傳統的前後端耦合的模式可能會成本更低、效率更高。
總之,即使現在前後端 分離的技術架構 很流行,但我們也不能瞎跟風,為了分離而分離,一切都要從業務需要和團隊技能情況出發。
如何實現 前後端技術 分離?
相信細心的讀者已經發現,我們本節 談 的是前後端 技術的分離如何去實現,因為近幾年還有一個 高大上的職位名稱在 網際網路圈很流行,那就是 全棧工程師,比如Facebook喊出了,他們只招 full stack 工程師的招聘口號,同時開源了 react這個劃時代的前端技術棧,並且他們在專案中也大量使用 node作為 後端開發語言。
關於 全棧 的概念,網上其實也吵得比較厲害,這裡不多說,其實我覺得 關鍵就是正確認識自己,能力強的就多學點、多幹點,自然而然就成了全棧工程師了,而對於多數像我這樣普通的開發者,還是老老實實幹好自己 領域內的事情,從個人成長和職業規劃上更有力。
回到本節主題,我們要實現的不是 前後端 分工 的分離,而是技術架構的分離:讓前端專注於檢視層、互動邏輯和前端控制層(可選,如Nodejs);讓後端專注於控制層(Restful API)& 服務層 & 資料訪問層。
前後端各自分工,API完成之前,前端人員一般使用mock server獲取假資料實現UI設計及互動,後端人員自己進行API單元測試,不用互相等待;API完成之後,後端部署到非線上伺服器,通過nginx 做反向代理各種資源和服務的請求,前後端再對接聯調;最後釋出上線的時候,各端釋出各端的工程,一般多數後端使用jekkins,多數前端工程通過CI進行自動的構建和打包釋出上線系統新需求。
對於小白,看完前面的回答,多數估計還不理解如何去實現前後端分離,我再補充一下我們真實專案的例子,但不會細化到程式碼層面哈。這裡以我們部門所有人都參與的淘車拍 車商管理和二手車源拍賣 系統為例,簡單分享一下哈。
業務場景:為二手車商提供一個管理公司車輛、交易訂單、客戶和員工的日常管理,以及評估、整備和牌證等管理,參與二手車源競拍等功能的Saas平臺,車商員工需要通過原生APP進行日常辦公,管理層或錄入大量表單時需要通過PC端進行操作,而某些功能 如 車源競拍還需要可以分享車源到微信進行導流及開闢小程式裡快速參與車源拍賣,後端還需要呼叫 大量兄弟部門和合作方的服務等,最後還會涉及金融,進行相關的風控稽核等。
前後端 技術分離方案:客戶端包含Android(基於Java)、IOS(基於OC), h5(基於vue技術棧,通過webpack啟動本地node伺服器代理後端介面請求),pc 端web頁面(基於自研的ecui技術棧,通過啟動和配置本地的ngnix伺服器代理請求),小程式(基於官方開發工具和文件),原生app會嵌入h5的頁面,客戶端的各端都有各自的工程,都是獨立開發和上線部署,然後通過Restful 風格的API以JSON的資料格式和後端進行互動,前後端完全分離,在伺服器上通過Ngnix分發前端靜態資源和java後端的介面服務的請求,舉例來說,車源拍賣的某些介面,如所有正在拍賣的車源,ECUI開發pc後臺、h5頁面和小程式 請求的都是同一介面,返回都是同樣的json資料。
前後端 技術分離的方案有很多,比如API 介面設計可以使用以資源為核心Restful,還可以使用以操作為核心REST-RPC介面風格;資料也未必一定是JSON格式的,也有XML,特定的二進位制等等;前後端的技術棧 更是數不勝數;而且也不一定非要用ngnix做代理分發伺服器,所以具體如何實現,需要大家結合實際去做技術選型。
一些易混淆的概念
前後端分離 VS 單頁應用
前後端分離:頁面全部通過ajax獲取資料並進行處理;初級分離--頁面和後端程式碼都部署在一起,但是程式碼雖然在一個專案中但是是分開的,頁面只處理渲染和跳轉,不處理資料,後端程式碼只處理資料,不管渲染和跳轉;高階分離--前端程式碼和後端程式碼分開部署,開發團隊分成前端和後端兩個團隊,只由API介面這個紐帶連線。
單頁應用:一個應用的所有內容在一個頁面中,一次性進行載入,使用者操作時顯示頁面的不同內容,這要求單頁面應用需是資料由API介面獲取的,也即是前後端分離的;多頁面應用,則是資源分佈在多個頁面中,使用者操作時,在多個頁面中跳轉。
前後端分離加上SPA的情況下,後端除了關鍵路徑帶認證那種的請求給你重定向之外,一般的路由邏輯都是前後端共享的,部分處理邏輯也是前後端共享,並且後端提供資料介面,與介面相關的資料處理邏輯就是後端獨有
前端分離 VS 後端渲染
後端渲染:後端的程式在把html頁面吐給前端之前,先把html頁面上的特定區域,特定符號,給用資料填充過,再扔給前端,這就是後端渲染。
前端渲染:後端的html頁面作為靜態檔案存在,前端請求時後端不對該檔案做任何內容上的修改,直接以資源的方式返回給前端,前端拿到頁面後,根據寫在html頁面上的js程式碼,對該html的內容進行修改。
傳統後端渲染 VS ssr服務端渲染
以前的伺服器渲染,是以“文件”為核心思想。伺服器端的邏輯是把HTML, CSS, Javascript當作一個靜態檔案,對“文件”而言不存在“指令”和“資料”的區別,一切都是資料。所以我們可以看到之前伺服器渲染,諸多服務端框架最基礎的元件之一就是文件模版,比如JSP之類,核心設計理念就是HTML檔案裡放佔位符然後由服務端邏輯替換成實際資料後一股腦返回。
Web 2.0時代最大的思想革命本質不是前後端分離,而是把網頁當作獨立的應用程式(app)。前後端分離只是實現這一新架構的必然結果。對程式而言指令和資料是分離的。HTTP GET拿到的不是渲染後的網頁,而是一個由html和Javascript組成的app, 這個app以瀏覽器為虛擬機器。裝載和顯示資料是app啟動之後的執行邏輯。
現在的伺服器渲染的目的只是為了加速和搜尋引擎優化(準確的說是非Google引擎優化,因為Google可以解析Javascript動態網頁)。而實現也很簡單:拿個瀏覽器核心跑一下app然後把生成的html存起來給搜尋爬蟲就行了。與其說是渲染,不如說是“快照”,就像給app截圖一樣。
相關文章
- 再談前後端分離後端
- 淺談前後端分離中的跨資源共享(CORS)後端CORS
- 談談前後端分離及認證選擇後端
- 淺談前後端路由與前後端渲染後端路由
- 前後端分離那些事後端
- 前後端分離——使用OSS後端
- 前後端分離整合SpringSecurity後端SpringGse
- 淺談前後端分離思想對自由泳練習的指導意義後端
- vue前後端分離修改webpackVue後端Web
- 前後端分離——資料mock後端Mock
- 前後端分離Ajax入門後端
- ???前後端分離模式的思考???後端模式
- 前後端分離後模組開發後端
- 前後端分離的優缺點後端
- Laravel 前後端分離 csrf 防護Laravel後端
- spring shiro+cas 前後端分離Spring後端
- 實現前後端分離的心得後端
- 前後端分離之Ajax入門後端
- 從部署上做到前後端分離後端
- Flask前後端分離專案案例Flask後端
- 簡單的前後端分離 Cas後端
- Cloudera Manager 前後端分離部署方法Cloud後端
- node-vue前後端分離記錄Vue後端
- axios前後端分離下載檔案iOS後端
- 用jQuery怎麼做到前後端分離jQuery後端
- 前後端分離前端模擬資料後端前端
- Web前後端:如何分離,如何解耦?Web後端解耦
- jQuery 前後端分離專案總結jQuery後端
- 前後端分離開發腳手架後端
- 前後端分離開發部署模式【轉】後端模式
- 前後端分離的好處有哪些?後端
- 前後端分離技術路線圖後端
- 前後端分離之更好的mock你的後端api後端MockAPI
- ruoyi vue 前後端分離版本 打包分離jar包至libVue後端JAR
- 前後端分離,後端用springboot遇到的跨域問題後端Spring Boot跨域
- Nginx代理同域名前後端分離專案Nginx後端
- SpringBoot+Vue前後端分離系統搭建Spring BootVue後端
- 前後端分離解決跨域問題後端跨域