关于互联网应用前端架构的一些思考

一、互联网应用的分类

讨论前端架构之前，首先要弄清楚互联网应用的类型，明确了自己的产品所属的类型才能打造属于自己的架构。对互联网产品进行分类，网上有很多不同的观点。我觉得分类是多维度的，但是按照交互以及功能的复杂程度来分类是比较客观的。因此，我比较认同淘宝玉伯在关于前后端开发模式中对应用的分类，以下引用玉伯的观点：

前端涉及的产品形态在业界可分为两大类：Web Pages 和 Web Apps 。

Web Pages 是浏览类的，用户主要是来看的：以内容展现为主，辅有少量交互。前端提供基础类库，开发工具化、外包化。典型：首页、营销活动、频道等等。

Web Apps 则以交互为主，用户主要是来用的。可分为两种：

体验类：包含大量交互，同时用户体验很重要。比如 GMail, 支付宝收银台、淘宝购物车等等。
功能类：包含大量交互，以功能为主，体验不是第一位的。比如后台系统、认证流程等。

Web Apps 的开发，前端投入了大量人力，但前端资源依旧存在潜在的瓶颈（比如新增加一条业务线时，很可能无前端去支持）。现有前后端配合的开发模式，沟通协作成本偏高，可维护性不够方便。在现有的研发模式下，前端自身的价值点也很难体现出来（花了大量时间在业务上，但得到的认可不多）。
最核心的问题，依旧是前后端的解耦：如何让前后端的工作彼此更独立，如何让更合适的人做更合适的事，把事情做得更好。
对于体验类，目前业界有很多新兴的解决方案：Backbone, Ember, Knockout 等等，包括 YUI 的 App framework 等。这些解决方案，都希望后端专注于提供 REST 接口，其他的都交给前端来搞定。
对于功能类的，目前业界解决方案依旧是比较老的一套，比如 GWT 等，包括 ExtJS 也是希望能让后端搞定一切。

二、体验类应用在架构层面要解决的问题

我们知道了自己的产品所属的类型，也知道了每一种类型业界已有的一些解决方案。是不是引入这些成熟的解决方案就可以了？实际的应用场景要复杂很多。要知道任何一个开源框架都有他的适用范围，不可能跟自己的应用100%匹配。举例说明，以下这些通讯层的需求是比较常见的：

（1）统一拦截http请求，转换请求报文格式（json转xml等）

（2）接口超时或者异常则上报日志

（3）统一拦截http响应，非法JSON解析异常进行日志上报，转换响应报文的数据格式（xml转json等）

（4）添加统一的请求头部

（5）html5分块上传的特殊处理

如果我们的MVC框架选型为backbone，要满足这些需求我们不得不去修改backbone的通讯层源码（你会发现backbone的通讯层其实是对jquery的ajax方法的又一次封装）。如果这种需求场景过多，我们就得频繁的修改源码，最终代码将变得难以维护。引入框架必将失去一部分灵活性，这是代价。记得不久前，在infoq上看过一个facebook的前端工程师的视频，他对前端趋势的部分观点，我比较认同：前端未来的趋势应该是去框架化。每个公司都应该根据自己的产品类型，打造属于自己的框架。当然在这个过程中我们可以吸取优秀框架的思想，甚至对开源框架进行必要的裁剪，复用核心功能。在架构层面我们通常至少要解决以下问题：

1、模块化

2、视图与数据解耦

3、视图与视图解耦

4、健壮的通讯层

5、DOM操作

6、工具库

7、业务层代码的水平拓展

8、减少重复代码

9、静态资源的版本管理

10、语法检查、自动打包

三、为体验类应用打造框架

（1）模块化。AMD（require.js、curl.js）、引入命名空间