聊一聊WEB开发阶段ajax的模拟与联调

昨天一个前端同事问我,MAC如何连接到局域网的共享文件夹,我思索了一下,想起来Finder里有个菜单选项”前往”->”连接服务器”,在弹出的对话框中,输入网络地址,比如smb://192.168.xxx.xxx,然后回车即可(顺带提一下,WINDOWS的话,在任一文件夹地址栏或WIN+R,输入 \192.168.xxx.xxx,回车即可)当然这不是本文的重点。后来了解到,是某后端同事要求刚才那位前端同事以这种方式和他联调ajax,号称可以“立即看到效果”,当时我就震惊了o(╯□╰)o,遂决定聊一聊这个话题。
早期,互联网站点基本都是“瘦客户端”,即无异步请求,设计师(或者叫美工?)把psd变成网页后(或添加一些简单的脚本效果),交给“WEB开发攻城狮”填充数据,Done。然而,随着互联网的普及,用户体验的要求越来越高,各种异步请求被引入,后来出现了“胖客户端”甚至单页应用。起初,javascript仅用于表单校验或简单的动画效果,后来为了提升用户体验,javascript的代码量日益增长,尤其是异步请求的增多,WEB开发攻城狮的负担越来越重。

后来,为了提升用户体验,越来越多的公司把WEB开发中的前端开发工作独立出来交给“前端攻城狮”(早在2001年,雅虎就诞生了世界上第一个前端工程师岗位),让后端同学能够更加专注业务。而不像以前,从前端到数据库一个人统统搞定。那么问题来了,由于不是一个人完成某个功能,就涉及到联调(或者叫做数据对接),尤其是ajax。终于说到主题了囧。在开始开发前,通常前后端会约定好ajax请求的往返数据结构,然后各自朝着这个终点行进。通常有这几种方式:

一.ajax访问静态文本模拟响应

这是最简单的方式,以jquery为例:

1
2
3
$.ajax('mock/test.json').done(function (data) {
//do something
})

然后,写好mock/test.json:

1
2
3
{
"greeting":"hello"
}

触发上面的ajax即可拿到上面模拟的这个对象。

如果你是以file协议打开静态页面,在chrome下是被禁止的,需要为启动程序添加参数,windows参考 这个帖子 。推荐使用webstorm这个IDE,打开html默认以访问服务器的方式打开,就没有这个问题了,或者windows自带的IIS服务器。
优点:

简单,不依赖后端

缺点:

  1. 这种方式需要写一个指向本地的url,也就是说,当你模拟ajax完成后,最后提交代码时,仍然需要修改url地址指向正式的地址
  2. 自己模拟的数据与最终后端提供的数据难免有出入,集成进后端时比较可能需要继续修改代码。

二.本地页面直接访问后端服务

等待后端提供好ajax接口,启动web服务,本地打开页面,发起ajax请求,拿到比较真实的数据。当然,这会产生跨域问题,可以利用html5的Allow-Control-Allow-Origin: * ,来允许跨域。如果这个web服务是启动在后端同学的电脑上,那么你就非常可能受他影响了,一旦他的服务挂了,你就无法请求数据了。如果有一台公用服务器来启动这个服务,情况会好些。

优点:

能够拿到比较真实的响应数据,自己调试好后,基本就不用改代码了。

缺点:

  1. 需要额外处理跨域问题,或者可以使用jsonp来避免跨域问题
  2. 依赖后端的进度,受服务器影响大
  3. 开发时的请求地址与最终的请求地址还是会有些许不一致,开发时的ajax地址肯定需要以协议+ip/域名为前缀

三.本地启动项目web服务

等待后端开发好ajax接口,更新代码,在自己电脑上启动项目的服务,比如tomcat,jetty,甚至PHP的wamp。访问本地服务的页面,发起ajax请求。

优点:

ajax地址即为最终的地址,取到的数据结构也是靠谱的,调试通过后,也基本不用改。

缺点:

  1. 依赖后端的进度
  2. 需要在本地启动项目web服务,可能会比较占用资源,对机器性能有要求

四.ftp连接公用服务器

等待后端开发好ajax接口,在公用服务器更新代码,部署服务并启动。使用ftp工具,将修改后的代码上传至服务器,然后访问该服务器上的服务即可看到效果。webstorm提供了remote host功能,经过适当的配置,即可映射本地代码到服务器代码,当修改完本地代码并保存,将自动上传该代码到服务器,然后回到浏览器刷新即可看到修改效果。我还见过这么干的:本地修改完代码,提交,ssh更新服务器代码,浏览器刷新。效率太过地下,就不单独列出来了。

优点:

  1. 也能取得靠谱的数据,ajax地址也是最终的
  2. 由于修改的是公用服务器上的代码,可访问到这个服务的人都能立即看到效果。
  3. 相对于上一种,不用在自己机器上起服务了,节省了机器的内存与cpu
    缺点:

  4. 依赖后端的进度

  5. 有的公司前后端共用这台服务器,如果后端由于某种需要(特别是java),重启服务起,那么你将无法继续调试ajax

五.本地启动轻量级服务,动态分析ajax请求并响应

这也是我目前使用的方式,尤其是单页应用,会产生大量ajax,更加适合这种场景。

通过NodeJS平台的Grunt构建工具,启动node服务(我用的是grunt-connect),拦截ajax请求,动态分析url路径,返回不同的模拟响应。ajax地址可以任意指定,只要做好相应结果的映射或动态分析。

优点:

  1. 不依赖后端,甚至不依赖局域网,本机即可搞定
  2. 如果逻辑正确,调试通过的代码将不用做任何修改,包括ajax地址
  3. 轻量级web服务,不会占用过多资源
  4. 拦截ajax,动态分析,灵活度很高
    缺点:

  5. 由于是模拟响应,与最终后端提供的响应可能有些许出入,数据交互逻辑上,后期集成进后端时可能需要修改

  6. 需要掌握Grunt等工具的用法,加大了复杂度
     

 

总结

以上的模拟/联调方式,各有优缺点,也可以结合起来使用,以提高工作效率。

ps:开篇提到的那种方式,个人不建议使用,因为连版本控制都无法使用了,代码痕迹都无从保存,而且要求网络稳定,直接改别人电脑上的文件,总感觉不妥。