关于邮箱前端架构的一些思考

因为自己到现在都在搜狐实习，并且部门总监也是一个技术强烈热爱者，所以就有幸参与到前端邮箱的开发中来。 在接受这个任务的时候，由于自己对前端框架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，用于接口请求的鉴权。具体的过程可以看这里  或这里。

以上是我对邮箱架构的思考，在功能板块这里还有许多东西要讲，未完待续哦~