开始
rrestjs是我无意中确是有意接触到的一款类似却又不似express的nodejs开发框架。
为什么这么说呢?
因为我在使用express的时候,特别不爽,主要是路由这块,一堆一堆的配置,而且这个配置还是不可控的,怎么说呢。比如:app.get(’/get/:id’, function(){});假如用户访问的地址是:/get/test也将会跑到这块来处理。虽然在express 3.0版本增加了一 >个next方式,让这块处理可以转移到别的路由去处理,但是感觉还是不是很爽。然后开始琢磨是不是有更好的基于nodejs的框架呢。google了一下,然后就发现了rrestjs。
之后就是看里面的例子,发现很不错,试用了一下也非常棒。里面的想法和实现,深深的震撼了我,因为那就是我要找的,而我找到了。
然后毫不留情的说服身边的人,把之前基于express构建的变成基于rrestjs构建的。
事情的开始就是这样子的了。
rrestjs路由
然后,很有必要说说rrestjs的路由。
rrestjs的路由在包裹在try{…}catch(e){}里的一段代码。非常短小,如下:
try{
require('./controller/'+req.path[0])[req.path[1]](req, res);
}
catch(err){
restlog.info(req.path.join('/')+'; '+err);
res.r404();
}
rrestjs在接收http请求时,对url进行了一次分解。比如:http://yansong.me/u/upload => req.path = [‘u’, ‘upload’]; 然后去require(’./controller/u’)之后再去调用里面的upload方法。对应的u.js就应该是这样子的:
// u.js
exports.upload = function(req, res) {
// your code here
};
而如果不存在./controller/u.js或者不存在upload方法时,就会报错,然后自动转向了catch的处理模块。
如果你看过其他后端框架的处理模式,比如:PHP类的框架。你就很能明白这种思想理念所在了,以及它的便捷性了。
后记
说完rrestjs路由,我的主体思想大概就说完了。
非常感谢与rrestjs的作者本人snoopyxdy沟通,中间碰到了很多的一些问题,得以很快解决和理解。
之后打算写一个关于rrestjs路由的改进方案。。。
欢迎来我的github博客yansong.me共同讨论。
@yansong 顶你拉,我也是老吴的忠实粉丝,也是rrestjs比较早的收益人,以后我们多多交流。
自己也尝试的做过路由解析,还算比较简单,但是老吴把很多东西都做了封装改进,效果比我的那个好很多。自己还做过类似java的package机制,书写比较简单,可是没多大意义。3月份用的老吴的框架,后来改成自己的框架,再后来觉得老吴的框架确实很不错,又切回去了,哈哈,老吴大神。。。。
我还跟老吴说,让他建个群,大家多交流交流。。。
能在这上面碰到跟我一样的人,多多交流交流哈~~~
@a272121742 @yansong 托出现了啊, 哈哈,不是我的小号啊!有了你们的支持我更有动力把项目进行下去了,现在20几个人fork几乎没有人pull代码,桑心啊。
rrest是否支持express格式的模板引擎呐?打算把这个模板加进去https://github.com/leizongmin/express-liquid
没事,等我项目忙完了帮你一起改进
###哦哈~
还等着你把那个tploption功能变动态,挂到res下呢!
@snoopy rrestjs这种思维跟thinkphp一样啊,如果我想/users这样的路由如何映射呢?比如/users映射到Controller:user,action:list
@.@名字好听才会火。
我在文章里说了,/users => users.js文件
@snoopy 你取的名字不好记啊! ;-)
为什么这样就好呢?我觉得express的路由很好啊,体现了处理链的思想,跟filter很像,这样处理起来很爽,能把不同的逻辑的代码分开而不是统统放到一个处理函数离去
没错,链式处理很灵活 即使不想使用next(‘route’) 也可以通过将需要单独处理的router前置解决,无非是个代码组织加载的问题 个人感觉try catch 也没有errhandler来的优雅~
@yansong 也是后端程序员出身,不觉得express需要配置什么,没有说rrestjs不好,只是觉得express的路由解析已经做得很好,灵活性很强,扩展性也很强,理解起来也简单易懂,仁者见仁吧
不知怎么就被当前端了 赫赫赫 这么点儿内容真谈不上什么奥秘, lz之所以觉得rrestjs比较方便,是因为那短短一行代码里,背后体现的是约定大于配置的组织方式,即reqpath的namespace/resource/component对应controller下一个module
从路由性能上来说rrestjs更快,因为不用匹配路由的正则集,但如@saber 所说express的方式更灵活;
至于config,你完全可以自己写一个,按照自己实际的需要 btw: lz说的next express老版本就有了
http://cnodejs.org/topic/505c33ee10ccdf8077088e0a
比如说上面这个链接是怎么路由的?总不能为每一个ID都写一个函数吧?
思路很清晰,不过实现的感觉有点粗糙,如果增加更多的优化 效果可能非常不错啊!
顶一个!
提供的例子约定必须是2层路由,上面这个url路径只需要修改为: /topic/info/505c33ee10ccdf8077088e0a 即可
哪方面优化呢?
@snoopy 这个可以变通一下的
if (/\d/.test(req.path[1])) {
require('./controller/'+ req.path[0] + '/index')(req, res, req.path[1]);
}
同理,比如约定为.html为后缀,这是最常见的方案。像这样: http://cnodejs.org/topic/505c33ee10ccdf8077088e0a.html
写错了。
if (/\d/.test(req.path[1])) {
require('./controller/'+ req.path[0]).index(req, res, req.path[1]);
}
就像@lonevan 说的一样,约定大于配置
@snoopy 我提交了一个问题在github上,其实必须是2层路由是不是限制性太强了点,如果想配置3、4、5层路由就无法实现了不是。
express其实可以配置的
app.all('*', function (req, res, next) {
var path = req.path.split('/');
try{
var route = require('./controller/'+path[1]);
var fn = route[req.path[1]];
fn(req, res);
}
catch(err){
next();
}
});
此贴必火,老吴准备迎接你的粉丝吧
哈哈~有MM吗?0.9.3版本发布了,解决了你的2个问题啊,快去查收吧~
一开始我也是写了一个模块依附在express上的,但是后来发现这样做性能太差。
@snoopy 嗯,好的
@snoopy 相对来说我还是更喜欢express的,同样的url在处理完输出到浏览器之前可能有好多个环节.express就比较好.如果不是完结,直接next就好了.
@rekey 嗯各人有自己的喜好,喜欢什么风格用的顺就用什么
js强啊,回调,闭包,java 要1.8才有闭包功能