此博客不再维护,博客已迁移至 https://github.com/purplebamboo/blog/issues
文章目录
  1. 1. 那些年被虐待的经历
  2. 2. 忍无可忍无需再忍
  3. 3. 想的更多点
  4. 4. 结语

作为一个前端,经常被各种环境困扰。古人说穷则变变则通。最近实在是忍受不了之前开发环境的总总弊端,下定决心好好整了整。

那些年被虐待的经历

鄙人公司目前后端开发还是主要以java为主,使用的是spring的架构。之前的开发情况是,前端切好静态页面,给开发去套vm。

显然这是一种特别效率低下的事情。开发其实很多时候不能理解我们的html结构,所以多数时候我们得跑到开发旁边,一起改vm。

后来开发说了,他们不管vm了,让我们写。好啊,我们写还自由点。可是我还是too young too simple。写vm,我们只能在本地跑java环境,这个包,那个包。这个依赖,那个依赖。经常是开发svn升级了一个包,我们这边就跑不起来环境了,然后又是各种找开发来帮忙整环境,苦不开言。这里深深鄙视下java,大部分时间都花在打包还有环境调试上了。

再后来我们想了个办法,嗯,有那种持续集成环境,就是一个线上虚拟机。我们不用本地跑vm了。不过问题依旧,经常性的环境挂掉。而且最大的问题是每次svn改了vm。都要去发布下。

再后来不能忍了,团队的大牛推荐了vagrant。可以本地跑虚拟机,采用分发的方式。开发跑vagrant。然后打包发给我们,这样环境就一模一样。而且是本地虚拟机,所以改了vm立马生效。听起来很美好,可是再次证明现实很骨感,环境还是经常性的挂掉,因为开发用的windows,而我们vagrant里面的跑的linux,还是不少差别。在开发帮忙调试了几次环境后,发现问题依旧。也越来越懒得帮我们看环境了。

再后来,又回到了原始的境地,前端跑到开发旁边调vm。调js。

忍无可忍无需再忍

就这样,我们一直忍受着这种开发模式。因为nodejs如今如火如荼的进行着,而公司内部各个bu都在考虑用node做前后端分离,我们一直期待着有一天,把view层抽出来。这样就不用再跑java环境了。java只提供http数据接口。整个渲染层交给node,由我们自己把控。还可以自己模拟数据。

想想还是有点小激动呢。

但是。。。现实还是再一次拍死了我们。因为开发,运维对node还是有点抵触的:

  • 认为这么新的东西。稳定性没有保障。
  • 而且vm用的好好的,干啥要换。使用了node中间层反而增加了前端的工作量,本来就资源不够了。
  • 对开发其实并没有特别的好处,只是方便了前端把控环境。

于是在我们老大跟他们讨论了几次后,node中间层一直在做ing。嗯,这个做的过程不知道要持续多久。

作为小p,推动不了这么大的全局性的改变。但是环境问题真的受!够!了!

偶然的情况下发现了velocityjs这个项目。于是想着完全可以用node来模拟java环境嘛,把vm跑起来不就好了。

说干就干,于是在后来一个比较小的模板展示的项目里,使用express搭建了一套环境。把vm跑起来了。并且vm上面的那些变量都是我们自己使用json模拟。

于是我们终于解脱了,不再需要跑java环境,还可以脱离java。把功能完全写好,各个逻辑都使用模拟数据验证完,然后跟开发联调基本就是分分种的事。

想的更多点

虽然我们在小的项目里尝试了。但是对于比较复杂的项目,还是觉得整体改造比较困难。后来商量了下,其实可以做一个命令行工具。进行一些简单的配置就可以把vm跑起来。没错感觉就是个启动服务的工具了。

其实除了vm渲染的问题,我们还面对不少困难。

  1. 本地静态服务,之前都是本地起一个nginx。来新人了,都得教半天配置。另外线上的静态资源有时是支持combo的。我们跑vm的时候都得把combo的资源人肉切分。
  2. 项目一般都是使用less编写。开发的时候需要使用gulp跑一个watch,或者使用koala这种工具。
  3. ajax请求无法模拟,做静态页面的时候。都是自己写个简单的php脚本,打出一些简单的数据,来模拟。
  4. 在线上环境调试时,不方便。线上引用的都是压缩的文件。虽然可以通过url变量控制引用不压缩的。但是修改代码的时候,还是需要本地改好,打包发cdn,一看效果不对又要回滚。后来想到用reres来映射线上js到本地。可是combo的资源映射起来就难办了。另外我们前端使用了一种打包技术,将html模板打包到js里面,所以直接映射js就少了模板。总之一直是一个头两个大。

总体来说,我们的环境太零散,太凌乱。用起来也是各种困难。

所以想着能不能搞个工具解决所有这些问题呢?

正好那段时间一直在玩koa。突然发现koa天生适合解决这个问题。于是说干就敢,制作了qfilter这个工具。

说白了使用koa开一个本地服务命令行工具:

  1. 开发一个静态资源中间件用来处理js,css,html请求,支持combo。
  2. 开发一个vm中间件,当请求是vm模板时就使用velocityjs渲染vm后返回。
  3. 开发一个ajax中间件,处理所有的ajax请求。
  4. 开发一个rewrite中间件来改写请求的url。
  5. 开发一个less中间件实时编译less。

我们看上面说的:

第一个问题,静态资源中间件就解决了。

第二个问题,先使用rewrite中间件来改写请求的路径url,把css的请求映射到对应的less文件,并且到下一个less中间件时实时编译返回的内容返回。性能上并没有啥大问题。

第三个问题,ajax中间件搞定,只需要指定个目录,写一些模拟数据就好了。

第四个问题,因为通过上面的一系列中间件,可以使本地环境跟线上环境一模一样。我们只需要使用switchsharp这种代理软件把线上的js请求都映射到本地的服务,线上的css请求会映射到本地服务,本地服务再请求对应的less,再实时编译返回。线上的combojs请求,映射到本地服务,本地服务自动分割合并不同的js返回给浏览器。并且是立即修改,立即生效,调试变得异常简单。

整体上的思路,就是线上线下的页面都是一样的,线上请求什么,线下开发也是一样的。但是请求过来了,返回什么内容是本地服务说了算,请求css,我映射到对应的less并且编译返回。请求vm,我渲染后再返回。只不过线上是直接请求的打包生成好的css。请求的也是java渲染好的vm。而这些本地的服务都能百分百模拟。

于是前端开发的时候,不需要跑java环境了,如果前面的人配置好了各个参数。新人只需要跑到环境根目录下运行 qf s 于是世界清静了。所有的环境都在这一行命令行里面了。环境不再碎片化。而且线上线下一套环境,无缝切换。调试也更加简单。解放了大量的劳动力。

最终产出了这个基于koa的工具 qfilter

结语

任何事情,不要期望着未来遥远的解决方案,与其等遥远的阳光,还不如先想办法解决当前寒冷的问题。将来node中间件必将彻底解决环境问题,解决前后端分离问题。其实我这种反而是旁门左道了,但是我觉得解决问题才是最重要的。更何况,其实qfilter不只是解决了vm的渲染问题了。

文章目录
  1. 1. 那些年被虐待的经历
  2. 2. 忍无可忍无需再忍
  3. 3. 想的更多点
  4. 4. 结语