網(wǎng)絡(luò)公司做網(wǎng)站注重前后分離

2016-10-30    分類(lèi): 做網(wǎng)站

網(wǎng)絡(luò)公司做網(wǎng)站注重前后分離,什么是前后端分離,傳統(tǒng)開(kāi)發(fā)模式相信很多做過(guò)Web開(kāi)發(fā)童鞋應(yīng)該都會(huì)經(jīng)歷這樣一種開(kāi)發(fā)模式,利用后端語(yǔ)言提供的模版引擎編寫(xiě)HTML/XML頁(yè)面,比如:PHP 開(kāi)發(fā)有 Smarty模板引擎Java web工程有jsp頁(yè)面Python 各個(gè)Web框架都有各自的模板引擎NodeJS 的express你懂得都有一個(gè)共同的特點(diǎn),服務(wù)器端后臺(tái)語(yǔ)言生成解析后的HTML/XML格式返回給客戶(hù)端,例如瀏覽器端訪問(wèn)直接返回解析好的HTML,瀏覽器直接就解釋執(zhí)行。在傳統(tǒng)的像ASP,JSP和PHP等開(kāi)發(fā)模式中,前端是處在一個(gè)混沌的狀態(tài)中,可以說(shuō)是沒(méi)有獨(dú)立的“人格”可言。前端負(fù)責(zé)切圖和編寫(xiě)靜態(tài)頁(yè)面模板,后端將數(shù)據(jù)渲染到前端提供的頁(yè)面模板中,最后將頁(yè)面渲染到瀏覽器展示。這個(gè)過(guò)程中,前端只提供頁(yè)面模板或者寫(xiě)一些JavaScript腳本,有的甚至JS腳本都是后端來(lái)寫(xiě),前端的作用只局限于切圖和樣式模板文件,這種角色就是傳說(shuō)中的“切圖仔”。前后端分離,不只是簡(jiǎn)單的代碼的分離。首先是要架構(gòu)上分離解耦,逐漸擺脫前后端在架構(gòu)上的依賴(lài),前后端各司其職,分開(kāi)部署在不同的服務(wù)器上,通過(guò)RESTful接口傳遞數(shù)據(jù)。減輕后端服務(wù)器的壓力,后端服務(wù)器不再負(fù)責(zé)頁(yè)面渲染,只負(fù)責(zé)輸入數(shù)據(jù),吞吐量提升了好幾倍。其次是邏輯分離,不分離的時(shí)候,對(duì)于業(yè)務(wù)代碼的界限很不明確,業(yè)務(wù)邏輯基本都放在后端,分離之后,前端也承擔(dān)了一部分不該后端來(lái)寫(xiě)的業(yè)務(wù)邏輯,數(shù)據(jù)處理更加清晰。最后是系統(tǒng)分離,同一個(gè)后端系統(tǒng),可以將同樣的接口數(shù)據(jù)提供給PC端、Mobile端和Native端等不同的前端終端,不需要為每一種終端提供一套接口。同樣,對(duì)于前端應(yīng)用來(lái)說(shuō),可以更方便的調(diào)用多個(gè)后端服務(wù)器的接口,處理和展示多個(gè)系統(tǒng)間的數(shù)據(jù)。為什么要前后端分離前后端分離,讓軟件開(kāi)發(fā)的流程更加清晰,解決了開(kāi)發(fā)階段的痛點(diǎn)。從前,前端不止要學(xué)習(xí)后端的模板渲染語(yǔ)法,還要配置后端的開(kāi)發(fā)環(huán)境,并不斷同步后端的代碼,這對(duì)于前端來(lái)說(shuō)是非常痛苦的。而現(xiàn)在,前端有自己的服務(wù)器,不需要再依靠后端服務(wù)器來(lái)支持項(xiàng)目運(yùn)行,如果在開(kāi)發(fā)階段,還可以使用mock數(shù)據(jù)(要先和后端確定接口數(shù)據(jù)結(jié)構(gòu)),擺脫對(duì)后端接口的依賴(lài),這樣極大的提高了開(kāi)發(fā)效率,系統(tǒng)分工也更加明確。前后端分離后,需要考慮哪些事情分離后的前端,不再是一個(gè)簡(jiǎn)單的HTML文件,已經(jīng)是一個(gè)獨(dú)立的應(yīng)用系統(tǒng)。除了要考慮頁(yè)面的數(shù)據(jù)渲染展示,還要用工程化的思想來(lái)考慮前端的架構(gòu),前后端的交互和數(shù)據(jù)安全等事情。架構(gòu)**前端應(yīng)用部署在Nodejs、Nginx或者Nodejs和Nginx組合的服務(wù)器上,通過(guò)反向代理轉(zhuǎn)發(fā)頁(yè)面請(qǐng)求到后端服務(wù)器,相當(dāng)于在傳統(tǒng)的流程中加了Nodejs這一層。**當(dāng)然,也可以用Nodejs服務(wù)器來(lái)承擔(dān)一部分負(fù)載均衡的工作,業(yè)務(wù)邏輯也可以放在Nodejs這一層來(lái)處理,例如:通過(guò)判斷請(qǐng)求是來(lái)自 PC 還是 APP ,將請(qǐng)求發(fā)到不同的后端服務(wù)器Nodejs的架構(gòu)中,分層如下讓我們來(lái)回想一下軟件開(kāi)發(fā)流程中的幾個(gè)關(guān)鍵環(huán)節(jié):(1)產(chǎn)品經(jīng)理提需求,畫(huà)原型;(2)UI設(shè)計(jì)師根據(jù)原型出設(shè)計(jì)圖;(3)測(cè)試團(tuán)隊(duì)根據(jù)產(chǎn)品原型編寫(xiě)測(cè)試用例,制定測(cè)試計(jì)劃;(4)架構(gòu)師根據(jù)原型編寫(xiě)API文檔;(5)前后端工程師基于API文檔完成業(yè)務(wù)開(kāi)發(fā);(6)測(cè)試、改BUG、發(fā)布。API文檔環(huán)節(jié)直接關(guān)系到了前端和后端兩個(gè)開(kāi)發(fā)團(tuán)隊(duì),也是整個(gè)軟件開(kāi)發(fā)流程中耗時(shí)大的環(huán)節(jié)。RESTful接口交互前后端分離之后,更多的是采用 RESTful 風(fēng)格的接口與后端進(jìn)行數(shù)據(jù)交互。(如果你們的項(xiàng)目還在使用靜態(tài)的API文檔,比如word文檔,那你們必定經(jīng)歷著巨大的痛苦)REST是“呈現(xiàn)狀態(tài)轉(zhuǎn)移(REpresentational State Transfer)”的縮寫(xiě),一種API的架構(gòu)風(fēng)格,在客戶(hù)端和服務(wù)端之間通過(guò)呈現(xiàn)狀態(tài)的轉(zhuǎn)移來(lái)驅(qū)動(dòng)應(yīng)用狀態(tài)的演進(jìn)。在 REST 樣式的 Web 服務(wù)中,每個(gè)資源都有一個(gè)地址。資源本身都是方法調(diào)用的目標(biāo),方法列表對(duì)所有資源都是一樣的。這些方法都是標(biāo)準(zhǔn)方法,包括 HTTP GET、POST、PUT、DELETE,還可能包括 HEADER 和 OPTIONS。RESTful的API設(shè)計(jì),使得后端通過(guò)接口向前端傳遞數(shù)據(jù),數(shù)據(jù)的格式通常是JSON這種通用的格式。對(duì)前端來(lái)說(shuō),只要后端返回過(guò)來(lái)的是RESTful的數(shù)據(jù)就行,不管后端是用Java寫(xiě),還是用python或PHP,拜托對(duì)后端的依賴(lài),做到前端系統(tǒng)的獨(dú)立。REST服務(wù)的調(diào)試:Postman 和 Insomnia使用模板引擎前后端分離之后,前端工程師需要將通過(guò)API獲取的數(shù)據(jù)呈現(xiàn)到頁(yè)面上,雖然也可以通過(guò)jQuery對(duì)頁(yè)面一個(gè)一個(gè)賦值,但是這種效率太低了,或者也可通過(guò)在JavaScript中拼接HTML,但是這種方式太難維護(hù)HTML代碼了,也很難閱讀。因此最好的方式就是使用模板引擎。前端的模板引擎跟后端模板引擎很相似,比如JSP或cshtml(razor),他們的語(yǔ)法都非常相似,他們所實(shí)現(xiàn)的功能也幾乎一樣:將數(shù)據(jù)綁定到HTML模板。VueJs和react都可以充當(dāng)這樣的模板引擎。我們最終沒(méi)有選用react而是選用了VueJs的原因只有一個(gè),那就是VueJs是真正的響應(yīng)式,而react改變model之后需要手工調(diào)用setState才會(huì)更新UI,這是完全無(wú)法忍受的。因?yàn)檫@個(gè)原因,我們只能選擇VueJS作為模板引擎。工程化構(gòu)建Nodejs不止可以用來(lái)做前端服務(wù)器,在開(kāi)發(fā)階段,它也能發(fā)揮很大的作用。前端生態(tài)的發(fā)展,是圍繞著Nodejs進(jìn)行的。用npm來(lái)管理項(xiàng)目依賴(lài),可以很好的維護(hù)和運(yùn)行在Nodejs環(huán)境上。打包工具grunt、gulp、webpack和rollup等,都是運(yùn)行在nodejs上,再結(jié)合語(yǔ)法編譯、打包部署等插件,將應(yīng)用輸入成一個(gè)完整的應(yīng)用。如果你使用了Angular、React或Vue框架,或者你使用瀏覽器暫時(shí)還不兼容的ES6語(yǔ)法,還需要在應(yīng)用打包前用babel將語(yǔ)法編譯成瀏覽器可識(shí)別的ES5的語(yǔ)法。SPASPA是單頁(yè)Web應(yīng)用(single page web application,SPA)的簡(jiǎn)寫(xiě),就是只有一張Web頁(yè)面的應(yīng)用,是加載單個(gè)HTML 頁(yè)面并在用戶(hù)與應(yīng)用程序交互時(shí)動(dòng)態(tài)更新該頁(yè)面的Web應(yīng)用程序。像Angular、React或Vue就是為了SPA而設(shè)計(jì)的,結(jié)合前端路由庫(kù)(react-router、vue-router)和狀態(tài)熱存儲(chǔ)(redux、vuex)等,可以開(kāi)發(fā)出一個(gè)媲美Native APP的Web APP,用戶(hù)體驗(yàn)得到了很大的提升。當(dāng)然,SPA也不是好的,也不是適合所有的web應(yīng)用,需要結(jié)合項(xiàng)目和場(chǎng)景來(lái)選擇。SPA有如下缺點(diǎn):初次加載耗時(shí)增加。可以通過(guò)代碼拆分、懶加載來(lái)提升性能,減少初次加載耗時(shí)。SEO不友好,現(xiàn)在可以通過(guò) Prerender 或 Server render 來(lái)解決一部分。頁(yè)面的前進(jìn)和后端需要開(kāi)發(fā)者自己寫(xiě),不過(guò)現(xiàn)在一些路由庫(kù)已經(jīng)幫助我們基本解決了。對(duì)開(kāi)發(fā)者要求高,由于做SPA需要了解一整套技術(shù)棧,所以,要考慮后期是否有合適的人選進(jìn)行維護(hù)。mock(模擬數(shù)據(jù))前后端分離框架中的API mock思路想要實(shí)現(xiàn)真正的前后端分離,那就必須得用好API mock(模擬數(shù)據(jù))。使用mock數(shù)據(jù)的好處有兩個(gè):前端開(kāi)發(fā)人員可以基于API文檔生成mock數(shù)據(jù),在后端開(kāi)發(fā)人員將API發(fā)布出來(lái)之前就可以完成整個(gè)業(yè)務(wù)流程的開(kāi)發(fā);使用mock數(shù)據(jù)能夠更低成本、更快速地,通過(guò)直接修改mock數(shù)據(jù)的方式,調(diào)試頁(yè)面樣式、調(diào)試頁(yè)面功能。全局的mock開(kāi)關(guān)為什么要設(shè)置這樣一個(gè)全局的mock開(kāi)關(guān)呢?主要基于以下兩點(diǎn)考慮:設(shè)置全局的mock開(kāi)關(guān)之后就不再需要針對(duì)每一個(gè)頁(yè)面設(shè)置mock開(kāi)關(guān),更容易維護(hù),避免項(xiàng)目中有多個(gè)mock開(kāi)關(guān)而難以統(tǒng)一開(kāi)關(guān)狀態(tài);如果發(fā)布時(shí)忘記將mock開(kāi)關(guān)給關(guān)掉,那么發(fā)布之后一運(yùn)行發(fā)布者就會(huì)發(fā)現(xiàn)mock開(kāi)關(guān)忘了關(guān),然后可以快速修復(fù)之后再重新發(fā)布,從而避免不小心將正式服更新為mock數(shù)據(jù)源。正是由于以上兩點(diǎn)考慮,我們的全局mock開(kāi)關(guān)可以幫助程序開(kāi)發(fā)者和發(fā)布者更不容易犯錯(cuò)。解決請(qǐng)求問(wèn)題前后端分離后,我們只需要Server端告訴我們Api URL即可,那么這會(huì)產(chǎn)生一個(gè)問(wèn)題:Ajax跨域。這里就不能使用一般的跨域解決方法去解決,比如jsonp,iframe信使等等,因?yàn)槲覀冞€有POST請(qǐng)求。于是Http Proxy類(lèi)工具就有用了,比如我就會(huì)在BrowserSync加入中間件判斷每一個(gè)請(qǐng)求,如果是/api前綴就會(huì)代理到API Server端,API Server端收到數(shù)據(jù)后再返回給BrowserSync,BrowserSync再返回給瀏覽器端。這樣就解決跨域請(qǐng)求的問(wèn)題生產(chǎn)環(huán)境有兩種部署,一種是放到后臺(tái)項(xiàng)目里,這就沒(méi)啥說(shuō)的,另外一種就是前后端分開(kāi)部署,那就在前端WebServer處理端寫(xiě)點(diǎn)轉(zhuǎn)發(fā)規(guī)則就好,如Nginx,Apache都支持。靜態(tài)資源路徑問(wèn)題如果你的項(xiàng)目有上傳資源功能,那自然就會(huì)產(chǎn)生用戶(hù)資源,那前后端分離后,如何來(lái)處理這個(gè)問(wèn)題呢?得先看模式。資源與后臺(tái)項(xiàng)目放一起,后臺(tái)處理完后需要返回前臺(tái)一個(gè)相對(duì)路徑,如果資源時(shí)一臺(tái)單獨(dú)的服務(wù)器,那就需要返回資源的絕對(duì)URL即可。會(huì)話(huà)Web項(xiàng)目最頭疼的就是無(wú)狀態(tài)導(dǎo)致會(huì)話(huà)問(wèn)題,傳統(tǒng)的Web項(xiàng)目都使用Session/Cookie,但在前后端分離,集群部署模式下這Session明顯缺陷太多。token方式已經(jīng)是當(dāng)前Web端解決會(huì)話(huà)的主流,并且有很多開(kāi)源好用的token生成管理程序,基本上拿來(lái)就能用。做網(wǎng)站公眾平臺(tái)每天為您分享原創(chuàng)Web開(kāi)發(fā)資訊,開(kāi)發(fā)經(jīng)驗(yàn),為您的技能充電。期待您的關(guān)注與分享,同時(shí)歡迎您留言,讓我們每天進(jìn)步一點(diǎn)點(diǎn)!

標(biāo)題名稱(chēng):網(wǎng)絡(luò)公司做網(wǎng)站注重前后分離
本文URL:http://www.bm7419.com/news45/56145.html

網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián),是專(zhuān)注品牌與效果的網(wǎng)站制作,網(wǎng)絡(luò)營(yíng)銷(xiāo)seo公司;服務(wù)項(xiàng)目有做網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話(huà):028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

商城網(wǎng)站建設(shè)