我与rrestjs的相遇,是惊喜,是开始。
发布于 12 年前 作者 yansong 9861 次浏览 最后一次编辑是 8 年前

开始

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共同讨论。

32 回复

@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来的优雅~

@lonevan @saber 你们还是没有理解rrestjs,我希望你们去用一下就知道其中的奥秘。

另外你们应该没有接触过后端的框架结构,很多后端语言框架都是通过解析url,然后寻找对应的路径,如果你们没有接触过的话就很难体会了。

并且,rrestjs不需要像express那样需要去配置很多,rrestjs的处理就是加了一个config配置文件,清晰明了。

@yansong 也是后端程序员出身,不觉得express需要配置什么,没有说rrestjs不好,只是觉得express的路由解析已经做得很好,灵活性很强,扩展性也很强,理解起来也简单易懂,仁者见仁吧

这里的讨论似乎是这样的情况:@yansong 习惯并中意于thinkPHP式的路由,而@saber@lonevan 比较偏爱java的filter。然后就出现了类似于单排轮和双排轮的溜冰鞋哪种好的争论…

不知怎么就被当前端了 赫赫赫 这么点儿内容真谈不上什么奥秘, 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 相对来说我还是更喜欢express的,同样的url在处理完输出到浏览器之前可能有好多个环节.express就比较好.如果不是完结,直接next就好了.

@rekey 嗯各人有自己的喜好,喜欢什么风格用的顺就用什么

js强啊,回调,闭包,java 要1.8才有闭包功能

回到顶部