摘要:如何去解決這些問題前后端分離大部分的互聯網公司都分成了前端團隊和后端團隊。方案一采用架構業界很多公司會采用,單頁應用的架構,這種架構是天然的前后端分離的。方案二淘寶的大前端方案中途島上圖是淘寶基于的前后端分離分層,以及的職責范圍。
我們遇到了什么問題?
1.前端無法調試后端未完成的 API:如果后端同學還沒有完成 API 開發,那么前端同學就不能對這個 API 進行開發。之前我們都是在代碼里直接通過給變量賦假數據,又或者是在后端 Controller 里直接 return JSON 的方式來進行調試的。這樣的方式很容易會出現的情況就是,每次提交 commit 都要把它刪除掉,有時忘了沒有刪除掉,那么提交歷史就會變得很臟。
2.沒有自動化測試:前端對接口的調用沒有做自動化的測試。
3.前端需要依賴后端開發環境:前端需要后端環境來在本地測試,像我們使用的方案就是 Vagrant + 虛擬機的來開發。這樣的方式其實很笨重,不但每次啟動虛擬機都得等一段時間,而且會占用一定的 CPU 和內存資源,拖慢機器。然而,前端需要的只是數據。
如何去解決這些問題? ——前后端分離
大部分的互聯網公司都分成了前端團隊和后端團隊。在軟件設計中,我們有一個思想就是 Separation of Concerns (Soc),也就是 關注點分離 的思想。既然我們采用了前后端由不同團隊開發的模式,那么我們應該有分治的思想,也就是說,我們要盡可能更多地關注自己從事的領域。
1.框架層面
前后端倉庫的分離:
整個前端工程使用git subtree從后端Git工程中切分出來。后端應用均使用同一個前端代碼庫。
前端只clone前端代碼,啟動前端工程。前端使用sever來mock數據渲染ftl模板以及頁面展示
2.開發層面
前后端約定好接口,各自開發;節約時間(但聯調的時間可能增加),接口有更新及時溝通
前后端分離 開發流程圖
上線可以只上前端或后端代碼
二.如何實現前后端分離怎么做前后端分離,我們認為的前后端分離
前端:負責View和Controller層。
后端:負責Model層,業務處理/數據處理等。
前后端分離插圖 前后端分工 1
試想一下,如果前端掌握了Controller,我們可以做url design,我們可以根據場景決定在服務端同步渲染,還是根據view層數據輸出json數據,我們還可以根據表現層需求很容易的做 Bigpipe,Comet,Socket等等,完全是需求決定使用方式。
實際上,現在很多的成熟的網站都沒有做到上面的設計,很多時候后端也負責一部分View的渲染,例如很多的后端模版,有的時候這是很需要的。所以我們現在所談的前后端分離,更多的是基于上面我們所遇到的問題出發,即基于現有的前后端共同渲染View,但前端又能獨立開發的優化角度出發。
方案一:采用 SPA 架構
業界很多公司會采用 SPA(Single Page Application,單頁應用)的架構,這種架構是天然的前后端分離的。所有的數據都是后端通過 JSON 的形式來傳遞到前端,前端本身也有自己的 MV* 框架,從物理上實現了前后端分離。
WEB服務中,SPA類占的比例很少。很多場景下還有同步/同步+異步混合的模式,SPA不能作為一種通用的解決方案。
方案二:淘寶 UED 的大前端方案(中途島)
Abc
上圖是淘寶基于Node的前后端分離分層,以及Node的職責范圍。簡單解釋下:
-最上端是服務端,就是我們常說的后端。后端對于我們來說,就是一個接口的集合,服務端提供各種各樣的接口供我們使用。因為有Node層,也不用局限是什么形式的服務。對于后端開發來說,他們只用關心業務代碼的接口實現。
-服務端下面是Node應用。
-Node應用中有一層Model Proxy與服務端進行通訊。這一層主要目前是抹平我們對不同接口的調用方式,封裝一些view層需要的Model。
-Node層還能輕松實現原來vmcommon,tms(引用淘寶內容管理系統)等需求。
-Node層要使用什么框架由開發者自己決定。不過推薦使用express+xTemplate的組合,xTemplate能做到前后端公用。
-怎么用Node大家自己決定,但是令人興奮的是,我們終于可以使用Node輕松實現我們想要的輸出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、異步,想怎么整就怎么整,完全根據你的場景決定。
-瀏覽器層在我們這個架構中沒有變化,也不希望因為引入Node改變你以前在瀏覽器中開發的認知。
-引入Node,只是把本該就前端控制的部分交由前端掌控。
淘寶 UED 的大前端方案的思想是非常先進的,在前端 HTML/CSS/JS 和后端 Java 之間,架設了一層 NodeJS,把 View 層和 Controller 層都交由前端團隊去開發,后端團隊只負責 Modal 層。然而,這種方案對項目的改動將非常大,改造成本非常高。做到了真正的前后端分離。這并不是我們所要談論的。有興趣的可以搜索下相關的文章。
方案三:構建 Mock Server
Mock Server 的概念非常簡單,就是在開發環境構建一個模擬的服務器,然后構建假數據(Mock Data),再利用構建的假數據來進行開發。
這種方法的好處:
靈活性高:它小到可以只攔截一個 HTTP 請求,對某一個 API 進行調試;大到前端可以完全使用 Mock Server 進行開發,在本地完全不需要跑后端服務器。所以它可以以非常平滑柔和的方式融入到前端項目的開發當中。
構建簡單:我們甚至只需要通過 Fiddler 或者 Charles 等抓包攔截軟件,就可以完成一個 Mock Server 的構建。
能自動生成 API:由于數據和接口都是確定的,所以我們可以利用它來創建 API 文檔,便于前后端開發。
能為自動化測試鋪路:同樣是由于數據和接口都是確定的,所以我們還可以利用它來做單元測試。
三.如何對我們的項目進行改造?前后端分離插圖 如何對我們的項目進行改造
四.具體的實現我們想要的Mock數據的樣子:
1.全工程的數據都要Mock;
2.在固定平臺上創建接口,接口的請求參數和返回參數靈活配置;
3.能通過簡單的命令實現數據的Mock;
4.只啟動前端工程,不啟動后端工程;
網上有很多的開源技術,可以實現Mock數據的功能;
1.sosoapi
Demo1
2.taobo rap的項目,RAP
Demo2
上面開源技術的優缺點:
特點:友好的圖形界面,完整的接口文檔
缺點:接口完全托管在網站上,安全隱患
簡單的數據偽造,只實現本地的數據偽造(無接口文檔)
1.Mock.js
使用參考
Ll
2.faker.js
API參考
Demo5
特點:安全性高,產生本地數據;根據語法產生對應的數據
缺點:無圖形界面,手動編寫接口文檔
很多時候,我們寫單頁面應用時,都需要啟動一個本地sever,這里推薦puer。簡而言之,Puer是一個可以實時編輯刷新的前端服務器;同時它還兼有模擬數據的功能。
文檔型
apiary
Se
swagger editor
特點:優美的接口文檔
缺點:無圖形界面,編寫文檔學習成本高;適合后端編寫接口文檔
總結:
如果要做工程性的,要建立起我們開始介紹固定站點,圖形化錄入和展示接口;并建立起和工程結合的mock數據功能。
如果我們只是開發單頁面應用,可以使用Mock.js來模擬單一化的數據。
如果要寫接口文檔,建議使用apiary。
簡單的先做以上的介紹。
[參考]:
https://www.zhihu.com/questio...
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/107876.html
摘要:延伸這里再順便提一下,新架構下的防御。不過,還有一點值得一提前后端分離框架下,路由由控制我自己要獲取的后端參數和需要用在業務邏輯的參數,在主觀上前端同學更好把握一些。 原文: http://feclub.cn/post/content... 背景 1、什么是CSRF攻擊? 這里不再介紹CSRF,已經了解CSRF原理的同學可以直接跳到:3、前后端分離下有何不同?。 不太了解的同學可以看這...
摘要:什么是前后分離前后端分離并不是什么新鮮事,到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時,不可避免的會遇到各種各樣的問題。搞了一個前后分離,需要分離部署。 探究 :深入聊聊前后分離架構 前后分離,一直是一個相當泛泛的問題,前后分離到底好不好?沒有絕對的對,沒有絕對的錯,業界就這個問題已經激烈的探討幾年了.出現討論的點在于:分離當然是好的,但是以什么樣的服...
摘要:什么是前后分離前后端分離并不是什么新鮮事,到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時,不可避免的會遇到各種各樣的問題。搞了一個前后分離,需要分離部署。 探究 :深入聊聊前后分離架構 前后分離,一直是一個相當泛泛的問題,前后分離到底好不好?沒有絕對的對,沒有絕對的錯,業界就這個問題已經激烈的探討幾年了.出現討論的點在于:分離當然是好的,但是以什么樣的服...
閱讀 1574·2021-11-23 10:01
閱讀 2969·2021-11-19 09:40
閱讀 3214·2021-10-18 13:24
閱讀 3464·2019-08-29 14:20
閱讀 2980·2019-08-26 13:39
閱讀 1276·2019-08-26 11:56
閱讀 2662·2019-08-23 18:03
閱讀 373·2019-08-23 15:35