關於郵箱前端架構的一些思考

因爲自己到現在都在搜狐實習,並且部門總監也是一個技術強烈熱愛者,所以就有幸參與到前端郵箱的開發中來。 在接受這個任務的時候,由於自己對前端框架angular比較熟悉,所以我的前端領導就讓我去架構郵箱去了。

突然來了一個這麼棘手的活兒,自己真的是壓力山大,因爲此次郵箱採用的是前後分離的開發方式,考慮的東西實在是太多太雜了,像什麼攔截器啊,前端數據緩存,路由,模塊之間的交互,公共組件,項目管理,版本控制等等都需要涉及到,這就給我出了一個難題,如何實現,組織,完善各個模塊是我在郵箱開發過程中不斷思考的問題。下面我來分享一些我在郵箱前端架構中的一些體會和心得。


1.項目目錄結構清晰明瞭,基於項目所使用的框架的功能來組件項目目錄。


項目目錄結構:

app

components

angular-1.5.x

jquery
tpls
img
css

js

common

controller
directive
fliter
model
service
app.js
scss
fonts
data
index.html
build


結合angular框架,我所創建的項目目錄如上所示


components是第三方庫的根目錄,所有使用的第三方庫都放在裏面,而團隊自己開發的庫放在js/common中。

tpls是一些模板文件,用過angular的同學應該都知道,它是用爲路由提供模板文件的。

scss是用來簡化css的編寫過程的,我們使用gulp來將它下面的.scss文件編譯成css目錄下的.css文件

data用於存放前端模擬後端數據時創建的json文件。因爲我們採用的是前後分離的方式,就不可避免的需要先寫些假數據進行調試。

js 用於存放與項目有關的js文件,旗下除了common都是angular中的組件

build 用於存放項目發佈時從app下打包出來的項目


這樣郵箱目錄的大致框架就出來了,這裏有一點建議就是當你在搭建項目目錄的時候,你需要考慮到你所使用到的技術,項目如何去打包發佈,團隊如何協同。一個清晰的目錄結構在後期的維護中可以減少很多工作量。

 



2.項目按功能模塊進行開發與版本控制工具git


考慮到郵箱是單頁應用,並且採用的前端框架是angular,所以項目的開發是按照功能板塊進行開發的,其實我個人覺得應用都應該按功能板塊進行開發,因爲不能按照功能板塊進行開發的項目,可能當前的架構還不是最優的,還有提升的空間。項目的開發當然不止我一個人,所以需要協同開發,這就涉及到了一個問題,關於代碼庫中的版本如何控制。在這裏我們使用的是git版本控制工具,按功能板塊創建branch,合併代碼的使用使用merge。雖然使用merge後項目的時間線上的提交很亂,但是我們還是沒有使用rebase,因爲rebase到master上的時候可能會不止一次的解決衝突,非常不利於團隊的合作,如果是一個人開發的話可以使用rebase。

 

3.各功能模塊的交互與郵箱系統的鑑權


按照各個功能模塊開發是非常有好處的,因爲你只負責自己的的功能板塊與暴露給其他功能模塊調用服務API,不用去負責其他板塊內對自己板塊的調用的邏輯。在郵箱開發過程中,我們使用service來實現功能模塊暴露給其他功能模塊調用的api,極大的簡化了在開發過程中業務邏輯的錯綜複雜帶來的巨大代碼邏輯。

由於項目時採用前後分離的方式,就免不了需要使用異步請求,所以在異步請求之上,我封裝了一層鑑權,在郵箱登錄之後將token保存在鑑權類的私有變量中,在請求的過程中將token放在header,用於接口請求的鑑權。具體的過程可以看這裏  或這裏

以上是我對郵箱架構的思考,在功能板塊這裏還有許多東西要講,未完待續哦~

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章