前后端不分離，是怎樣的尸红？大概也只有我們這些『老古董』們吱涉，才對(duì)此有更多感受。不對(duì)外里，那些寫(xiě) React 的人怎爵，可能會(huì)對(duì)此也有一些體會(huì)。
今天盅蝗，如果有一個(gè)前端開(kāi)發(fā)工程師說(shuō)鳖链，不知道前后端分離是什么。那么墩莫，要么是剛畢業(yè)不久的芙委，要么是從老版的公司里出來(lái)的員工，要么是剛從時(shí)光機(jī)里出來(lái)的狂秦。
前后端分離
我剛開(kāi)始接觸前后端分離的時(shí)候灌侣，正值它開(kāi)始慢慢擴(kuò)散的時(shí)候，也還沒(méi)有意識(shí)到它帶來(lái)的好處裂问。覺(jué)得它甚是麻煩侧啼，當(dāng)我改一個(gè)接口的時(shí)候玖姑，我需要同時(shí)修改兩部分的代碼，以及對(duì)應(yīng)的測(cè)試慨菱。反而焰络，還不如直接修改原有的模板來(lái)得簡(jiǎn)單。
可是當(dāng)我去使用這個(gè)符喝，由前后端分離做成的單頁(yè)面應(yīng)用時(shí)闪彼，我開(kāi)始覺(jué)得這些是值得。當(dāng)頁(yè)面加載完后协饲，每打開(kāi)一個(gè)新的鏈接時(shí)畏腕，不再需要等網(wǎng)絡(luò)返回給我結(jié)果；我也能快速的回到上一個(gè)頁(yè)面茉稠，像一個(gè) APP 一樣的體現(xiàn)這樣的應(yīng)用描馅。整個(gè)過(guò)程里，我們只是不斷地從后臺(tái)去獲取數(shù)據(jù)而线，不需要重復(fù)地請(qǐng)求頁(yè)面——因?yàn)檫@些頁(yè)面的模板已經(jīng)存在本地了铭污，我們所缺少的只是實(shí)時(shí)的數(shù)據(jù)。
后來(lái)膀篮，當(dāng)我從架構(gòu)去考慮這件事時(shí)嘹狞，我才發(fā)現(xiàn)這種花費(fèi)是值得的。
什么是前后端分離誓竿？
前后端分離和微服務(wù)一樣磅网，漸漸地影響了新的大型系統(tǒng)的架構(gòu)。微服務(wù)和前后端分離要解決是類似的問(wèn)題筷屡，解耦——可以解耦復(fù)雜的業(yè)務(wù)邏輯涧偷，解耦架構(gòu)”兴溃可要是說(shuō)相像吧燎潮，消息隊(duì)伍和前后端便相似一些，通過(guò)傳遞數(shù)據(jù)的形式來(lái)解耦組件规哲。
前后端分離意味著跟啤，前后端之間使用 JSON 來(lái)交流诽表，兩個(gè)開(kāi)發(fā)團(tuán)隊(duì)之間使用 API 作為契約進(jìn)行交互唉锌。從此，后臺(tái)選用的技術(shù)棧不影響前臺(tái)竿奏。當(dāng)后臺(tái)開(kāi)發(fā)人員選擇 Java 的時(shí)候袄简，我可以不用 JSP 來(lái)編寫(xiě)前端頁(yè)面，繼續(xù)使用我的 React 又或者 Angular泛啸。而我使用 React 時(shí)绿语，也不影響后臺(tái)使用某一個(gè)框架。
概念我們已經(jīng)清楚了，但是還有一個(gè)問(wèn)題：我們真的需要前后端分離嗎吕粹？
真的需要前后端分離嗎种柑？
過(guò)去，聽(tīng)說(shuō) TDD (Test-driven development匹耕，測(cè)試驅(qū)動(dòng)開(kāi)發(fā)) 可以改善代碼的質(zhì)量聚请，我們便實(shí)施了 TDD；接著稳其，聽(tīng)說(shuō) BDD (Behavior-driven development驶赏，行為驅(qū)動(dòng)開(kāi)發(fā)) 可以交付符合業(yè)務(wù)需求的軟件，我們便實(shí)施了 BDD既鞠；后來(lái)煤傍，聽(tīng)說(shuō) DDD (Domain-driven design，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)) 可以分離業(yè)務(wù)代碼與基礎(chǔ)代碼嘱蛋，我們便實(shí)施了 DDD蚯姆。今天，聽(tīng)說(shuō)了前后端分離很流行洒敏，于是我們就實(shí)施了前后端分離——這就是傳說(shuō)中的 HDD（Hype-driven Development蒋失，熱鬧驅(qū)動(dòng)開(kāi)發(fā)）。
前后端分離在過(guò)去的兩三年里桐玻，確實(shí)特別的熱鬧篙挽。但是我們?cè)趺床拍苤溃遣皇切枰@樣的架構(gòu)呢镊靴？
頁(yè)面交互是否復(fù)雜 铣卡？是簡(jiǎn)單的提供頁(yè)面給用戶瀏覽？或者想要支持復(fù)雜的用戶操作偏竟？
是否需要搜索引擎優(yōu)化煮落？如果需要的話，那么從一開(kāi)始我們就需要考慮后端渲染踊谋。
能提升開(kāi)發(fā)效率嗎蝉仇？如果不能有效的提升開(kāi)發(fā)效率，為什么要作死呢殖蚕？
是否會(huì)提供 API 給 APP轿衔？如果我們已經(jīng)有一個(gè) API 提供給 APP，那么要做這件事就很容易了睦疫。如果未來(lái)會(huì)有的話害驹，那么我們更應(yīng)該嘗試去分離。
前端的修改是不是非常頻繁蛤育？如果不需要經(jīng)常修改的話宛官，那么這種優(yōu)化便沒(méi)有優(yōu)勢(shì)葫松。
當(dāng)然了，如果老板說(shuō)底洗，我們需要前后端分離腋么，那就做唄！很多時(shí)候亥揖，一些技術(shù)決策都會(huì)由于戰(zhàn)略原因党晋，而發(fā)生一些有意思的變化。
前后端分離將遇到的那些挑戰(zhàn)
而徐块，當(dāng)我們決定需要前后端分離時(shí)未玻，我們?nèi)匀贿€需要面對(duì)一系列的問(wèn)題：
是否足夠的安全？如果我們?cè)O(shè)計(jì)出來(lái)的架構(gòu)不夠安全胡控，那么這一系列的操作都是白搭扳剿。我們?cè)趺慈ゴ鎯?chǔ)用戶數(shù)據(jù)，使用 LocalStorage 的話昼激，還要考慮加密庇绽。采用哪種認(rèn)證方式來(lái)讓用戶登錄，并保存相應(yīng)的狀態(tài)橙困？
是否有足夠的技術(shù)來(lái)支撐前后端分離瞧掺？有沒(méi)有能力創(chuàng)建出符合 RESTful 風(fēng)格的 API？
是否有能力維護(hù) API 接口凡傅？當(dāng)前端或者后臺(tái)需要修改接口時(shí)辟狈，是否能輕松地修改。
前后端協(xié)作的成本高不高夏跷？前端和后臺(tái)兩個(gè)團(tuán)隊(duì)是不是很容易合作哼转？是不是可以輕松地進(jìn)行聯(lián)調(diào)？
前后端職責(zé)是否能明確槽华？即：后臺(tái)提供數(shù)據(jù)壹蔓，前端負(fù)責(zé)顯示。
是否建立了前端的錯(cuò)誤追蹤機(jī)制猫态？能否幫助我們快速地定位出問(wèn)題佣蓉。
當(dāng)我們?cè)诓煌捻?xiàng)目組上嘗試時(shí)，就會(huì)發(fā)現(xiàn)主要的挑戰(zhàn)是溝通上的挑戰(zhàn)亲雪，而非技術(shù)上的局限勇凭。
前后端分離的核心：后臺(tái)提供數(shù)據(jù)，前端負(fù)責(zé)顯示
我曾經(jīng)有過(guò)使用 PHP 和 Java 開(kāi)發(fā)后臺(tái)代碼的經(jīng)歷匆光，仍然也主要是集中在前端領(lǐng)域套像。在這樣的傳統(tǒng)架構(gòu)里，編寫(xiě)前端頁(yè)面可不是一件容易的事终息。后臺(tái)只會(huì)傳給前端一個(gè) ModelAndView夺巩，然后前端就要撲哧撲哧地去豐富業(yè)務(wù)邏輯。
傳統(tǒng)的 MVC 架構(gòu)里周崭，因?yàn)槟承┰蛴邢喈?dāng)多的業(yè)務(wù)邏輯柳譬，會(huì)被放置到 View 層，也就是模板層里续镇。換句話來(lái)說(shuō)美澳，就是這些邏輯都會(huì)被放到前端。我們看到的可能就不是各種if摸航、else還有簡(jiǎn)單的equal判斷制跟，還會(huì)包含一些復(fù)雜的業(yè)務(wù)邏輯，比如說(shuō)對(duì)某些產(chǎn)品進(jìn)行特殊的處理酱虎。
如果這個(gè)時(shí)候雨膨，我們還需要做各種頁(yè)面交互，如填寫(xiě)表單读串、Popup聊记、動(dòng)態(tài)數(shù)據(jù)等等，就不再是簡(jiǎn)單的和模板引擎打交道了恢暖。我們需要編寫(xiě)大量的 JavaScript 代碼排监，因?yàn)闃I(yè)務(wù)的不斷增加，僅使用 jQuery 無(wú)法管理如此復(fù)雜的代碼杰捂。
輸出邏輯：數(shù)據(jù)顯示
而僅僅只是因?yàn)檫壿嫃?fù)雜的前端代碼舆床，無(wú)法影響大部分團(tuán)隊(duì)進(jìn)行前后端分離——因?yàn)樗鼪](méi)有業(yè)務(wù)價(jià)值。實(shí)際上是先有了單頁(yè)面應(yīng)用嫁佳，才會(huì)出現(xiàn)前后端分離峭弟。單頁(yè)面應(yīng)用可以讓用戶不需要下載 APP，就可以擁有相似的體現(xiàn)脱拼。并且與早期的移動(dòng)網(wǎng)頁(yè)相比瞒瘸，擁有更好的體驗(yàn)。
為了達(dá)到這樣的目的熄浓，后臺(tái)似乎返回對(duì)應(yīng)的 Model 即可情臭，稍微修改一下 Controller 的邏輯，然后返回這些數(shù)據(jù)赌蔑。
[{
????"content":?"",
????"date":?"2018-10-16",
????"description":?"前后端分離俯在，你應(yīng)該知道的八件事\r\n\r\n前后端不分離，是怎樣的娃惯？大概也只有我們這些『老古董』們跷乐，才對(duì)此有更多感受。不對(duì)趾浅，那些寫(xiě)?React?的人愕提，可能會(huì)對(duì)此也有一些體會(huì)馒稍。",
????"id":?1,
????"slug":?"iamafe-frontend-backend",
????"title":?"我的職業(yè)是前端開(kāi)發(fā)工程師:??前后端分離，你應(yīng)該知道的八件事",
????"user":?""
}]
前端在一個(gè) API 請(qǐng)求之后浅侨，可以直接渲染這些數(shù)據(jù)成 HTML纽谒。在這個(gè)時(shí)候，我們?nèi)匀豢梢钥吹饺缡洌厦鏀?shù)據(jù)中的 date 字段值 2018-10-16 的格式鼓黔，和我們?nèi)粘Ｓ玫?2018 年 10月 16 號(hào)的不一樣。所以不见，我們需要在前端引入 moment 這樣的庫(kù)澳化，然后解析這個(gè)值。如果僅僅是這樣的處理稳吮，那么應(yīng)該由后臺(tái)幫我們轉(zhuǎn)換這個(gè)值缎谷。
與此同時(shí)，后臺(tái)應(yīng)該按時(shí)間來(lái)對(duì)博客進(jìn)行排序盖高。前端只需要遍歷這個(gè)數(shù)組慎陵，隨后取出相應(yīng)的值顯示即可，不需要做任何的邏輯處理喻奥。
遺憾的是席纽，在真正的項(xiàng)目中開(kāi)發(fā)的時(shí)候，并不能達(dá)到這么完美的狀態(tài)撞蚕。特別是润梯，為了提高用戶體驗(yàn)時(shí)，我們可能就會(huì)將數(shù)據(jù)存儲(chǔ)在本地甥厦，隨后直接操作這些數(shù)據(jù)纺铭，對(duì)其進(jìn)行排序，篩選等等的操作刀疙。除此舶赔，還有諸如表格、圖表等等的高級(jí)樣式谦秧，也需要處理這些數(shù)據(jù)竟纳。
而當(dāng)用戶需要提交數(shù)據(jù)的時(shí)候，這些邏輯就會(huì)落到前端上疚鲤。
不可避免的前端邏輯：表單
如果一個(gè)前端應(yīng)用只顯示數(shù)據(jù)的話锥累，那么這個(gè)應(yīng)用就沒(méi)有充足的理由，做成一個(gè)單頁(yè)面應(yīng)用——單頁(yè)面應(yīng)用是為了更好的交互而存在的集歇。當(dāng)我們注冊(cè)桶略、登錄、購(gòu)買東西時(shí)，就需要開(kāi)始與表單進(jìn)行處理际歼。
合理的表單驗(yàn)證模式應(yīng)該是：雙邊驗(yàn)證惶翻。
前端在用戶輸入的過(guò)程中就需要實(shí)時(shí)地檢查，是否帶有特殊符號(hào)蹬挺、值是否是在允許的范圍內(nèi)维贺、是不是符合相應(yīng)的規(guī)范等等它掂。而不是等用戶填寫(xiě)完內(nèi)容并提交后巴帮，再由服務(wù)端來(lái)告訴用戶說(shuō)，“你的用戶名不符合規(guī)范”虐秋。
服務(wù)在收到前端收到的數(shù)據(jù)后榕茧，不管前端有沒(méi)有進(jìn)行驗(yàn)證，都應(yīng)該按后臺(tái)的邏輯進(jìn)行驗(yàn)證客给。
于是乎在這個(gè)時(shí)候用押，這些邏輯就被無(wú)可避免地放到前臺(tái)里了。
最后
“相信有很多想學(xué)前端的小伙伴靶剑，今年年初我花了一個(gè)月整理了一份最適合2018年學(xué)習(xí)的web前端干貨蜻拨，從最基礎(chǔ)的HTML+CSS+JS到移動(dòng)端HTML5到各種框架都有整理，送給每一位前端小伙伴桩引，53763缎讼，
1707這里是小白聚集地，歡迎初學(xué)和進(jìn)階中的小伙伴坑匠⊙福”
