[nodejs]Route design

[jason.桂林]

I tested that express is a little slower then non-express code. I planning to design a new web framework and I also design a benchmark tool, to make sure my framework is fast.

My basic thinking is fast routing, fast session, in memory cache and clean code.

The first step is fast routing, I use a mechanism multi routing, 

1st is hash routing, e.g. app.get('/user/login', login),  will routing by handlers['/user/login'](req, res);

2nd is multi hash routing, e.g. app.get('/user/:id/edit', editprofile), will routing by handlers['user']['*']['edit'](req, res);

3rd is match routing, e.g. app.get(/user\/edit-(\d+)/, editprofile), will routing by handlers.forEach(function(rule) { if(rule.test(req.path) handlers[rule](req, res) })

but before do this, I have to design the routing api. is sinatra like api good enough?  when I coding, I still need seprate the routings to different files, so we have below code

1: in app.js: 

  app.get('/user/login', routes.user.login)

or 2: in routes/user.js :

  var app = require('../app');
  app.get('/user/login, function(req, res, next) { // code here });

or 3 

in app.js:

   require('./routes')(app);

in routes/user.js

    module.exports = function(app) {
      app.get('/routes/user', function(req, res, next){// code here})
    }

Did you see the problem? 

We can just map  `get.user.login` to GET '/user/login' to save typing and ignore circulate dependency.

get/index.js
var app = module.export
// url: /  url: /index  goes here
app.index = function(req, res) {}
// url: /user goes here and all request of /user/* not found matchs goes here
app.user = require('./user')
get/user.js
// url: /user/  and url: /user/index goes here
user.index = function(req, res){}
// url: /user/login goes here
user.login = function(req, res) {}

but this method has a problem, how define param routing and regex routing?

What do you think about all these things? 

--
Best regards,

Jason Green
桂林

[Marak Squires]

http://blog.nodejitsu.com/ibm-doesnt-care-about-nodejs-people/framework.png

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[tjholowaychuk]

I can personally guarantee you routing will be less than 5% of your bottleneck, focus on real-world problems, and profile first

[Isaac Schlueter]

On Fri, Apr 27, 2012 at 21:01, tjholowaychuk <tjholo...@gmail.com> wrote:
> I can personally guarantee you routing will be less than 5% of your
> bottleneck, focus on real-world problems, and profile first

Yes. This is the Node Way. Build it the simplest way possible, then
benchmark and profile.

Have you seen https://github.com/aaronblohowiak/routes.js? I've been
using it a bit lately, and it's pretty nice. Very simple, nothing but
routing.

[jason.桂林]

under my test, routing is not only 5%. I will show my benchmark soon.

2012/4/28 tjholowaychuk <tjholo...@gmail.com>

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[tjholowaychuk]

@Jason are you profiling a real-world application? with database interaction etc, or just hello-world fun?

If you have a mission-critical end-point that is extremely hot you're best to just go with straight-up node

and no (or very specific) routing. Like I said though it's not like I'm against optimizing Express, but you

need to pick and choose parts of the code that are actually relevant

2012/4/28 tjholowaychuk <tjholo...@gmail.com>

nodejs+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[C. Mundi]

Where *did* you get that graphic?  LOL.

On Apr 27, 2012 11:46 AM, "Marak Squires" <marak....@gmail.com> wrote:

[jason.桂林]

@TJ you are right, I am using something like helloworld, but it is real-world application.

Why hello world is real-world application, because I use cache layer, even more, I can use a In-Process-Cache layer. So, the IO layer could be very fast.

I have done a very first version routing, here is my benchmark result.

express constant path routing

app.get('/', function(req, res) { res.send(); })

rps: 5943

express param path routing

app.get('/user/:userid', function(req, res) { res.send() });

rps: 5740


My small routing module, named kick.js, choose the same syntax with express

app.get('/', funtion(req, res) { res.end( 'hello world' ) })

rps: 7451

app.get('/user/:userid', function(req, res) { res.end( req.params.userid ) })

rps: 7180

on MacBook Air, benchmark with siege.js

https://github.com/guileen/kick.js

https://github.com/guileen/siege.js

2012/4/29 C. Mundi <cmu...@gmail.com>

Where *did* you get that graphic?  LOL.

On Apr 27, 2012 11:46 AM, "Marak Squires" <marak....@gmail.com> wrote:

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Arunoda Susiripala]

I think jason have a some point here.

What I feel is like this.

Express is not bad & it can be improved.

@TJ

Why are you so against on this discussion.

If I'm the author of express.

I'll ask jason to patch express and try to make his improvements into express core :P

Arunoda Susiripala

@arunoda

https://github.com/arunoda

http://www.linkedin.com/in/arunoda

[jason.桂林]

@ Susiripala I am afraid I can't. Why kick.js is faster because it is very simple with limited feature, it can NOT compatible with all connect middleware.

connect use EventEmitter to communicate between middlewares.

Routing could be improved in express, but how it chain the middlewares is different with kick.js I guess.

How kick.js handling the middlewares chain is show in the link

https://github.com/guileen/kick.js/blob/master/kick.js#L260-283

If you have any suggestion let me know, or send a pull request

2012/4/29 Arunoda Susiripala <arunoda.s...@gmail.com>

[jason.桂林]

What I said previously maybe wrong, kick.js can use connect middleware, just test logger, static, cookieParser, session, bodyParser

2012/4/29 jason.桂林 <gui...@gmail.com>

[Arunoda Susiripala]

:) 

Cool.

[tjholowaychuk]

I'm not against the discussion, things can always be improved, but
the
fact is for 99% of the applications out there you're doing much
more than just routing. Even then you should ask yourself if you need
it
or if you want it. Do you get 8000+ requests per second for that end-
point? Probably not,
if you do, then that's likely a good time to make it extremely
optimized with regular node http.createServer(),
which would be faster than your thing as well, so it all gets down to
a balance of productivity and
performance. Hell do you need it to be even faster? write it in C, or
realistically scale horizontally
and worry less about RPS of a single server. It's kinda like arguing
about which template
engine is faster, it's largely irrelevant.

On Apr 29, 3:42 am, Arunoda Susiripala <arunoda.susirip...@gmail.com>
wrote:

> :)
> Cool.
>
>
>
>
>
>
>
>
>
> On Sun, Apr 29, 2012 at 3:09 PM, jason.桂林 <guil...@gmail.com> wrote:
> > What I said previously maybe wrong, kick.js can use connect middleware,
> > just test logger, static, cookieParser, session, bodyParser
>

> > 2012/4/29 jason.桂林 <guil...@gmail.com>

>
> > @ Susiripala I am afraid I can't. Why kick.js is faster because it is very
> >> simple with limited feature, it can NOT compatible with all connect
> >> middleware.
>
> >> connect use EventEmitter to communicate between middlewares.
>
> >> Routing could be improved in express, but how it chain the middlewares is
> >> different with kick.js I guess.
>
> >> How kick.js handling the middlewares chain is show in the link
>
> >>https://github.com/guileen/kick.js/blob/master/kick.js#L260-283
>
> >> If you have any suggestion let me know, or send a pull request
>

> >> 2012/4/29 Arunoda Susiripala <arunoda.susirip...@gmail.com>

>
> >>> I think jason have a some point here.
> >>> What I feel is like this.
>
> >>> Express is not bad & it can be improved.
> >>> @TJ
> >>> Why are you so against on this discussion.
>
> >>> If I'm the author of express.
> >>> I'll ask jason to patch express and try to make his improvements into
> >>> express core :P
>

> >>>>> On Apr 27, 2012 11:46 AM, "Marak Squires" <marak.squi...@gmail.com>

> >>> @arunoda <http://twitter.com/arunoda>
> >>> <http://gplus.to/arunoda>https://github.com/arunoda

> @arunoda <http://twitter.com/arunoda>
> <http://gplus.to/arunoda>https://github.com/arunodahttp://www.linkedin.com/in/arunoda

[tjholowaychuk]

I should note that by "dont worry about RPS" I mean, worry about
latency, and scale horizontally. For example some things like
computing an ETag or gzipping may "appear" to be slower with something
like ab(1) or siege(1), but realistically it'll help improve
performance. So these types of benchmarks are pretty useless beyond
making sure you didn't mess up hardcore with some show-stopping bug

[jason.桂林]

@TJ you are right, compare simple kick.js with express is irrelevant. I will use node helloworld instead of express to do comparing.

Optimized with regular node http.createServer(), why I didn't realize that.

[tjholowaychuk]

I can get an easy ~10k rps with http.createServer(), but
still that's 864,000,000 requests in 24hrs with a single
process, if you're telling me you need that, then you
should probably optimize with http.createServer() :)