Ace - Sinatra for Node with Fibers

by maccman • 14 years ago

100 37 14 years ago

kodablah• 14 years ago

Might not be the best name for a JS lib/app since ACE is already a popular in-browser editor: http://ace.ajax.org/.

Also encouraging the use of node for synchronous processing (even when using coroutines) is unlikely to be high performing when scaled up. If you have work to do, it'd be best to defer to another service and let node work as a router.

nyrb• 14 years ago

+1 ACE Editor and Ace - Sinatra for Node might be confusing.

Maybe name it "Frank" (Frank Sinatra) or "Ray" (Ray Charles). :-)

apaprocki• 14 years ago

Not to mention the ACE C++ system, which has been around for years and is widely known: http://www.cs.wustl.edu/~schmidt/ACE.html

furtivefelon2• 14 years ago

very true, especially since node is single threaded, you might block other requests etc.

benatkin• 14 years ago

Well, the creators of ace (macmann and mjackson) are lucky that ACE is almost always used as an acronym in the Ajax.org Cloud Editor's marketing and documentation. Because of this and the sheer number of JavaScript programmers out there, I think they'll most likely be able to keep the name.

olegp3• 14 years ago

I've run benchmarks comparing plain Node to Common Node (my library that uses fibers) and the version with fibers uses marginally more memory and on average has 75% of the throughput of the purely asynchronous code.

You can find the benchmarks and results in the project README: https://github.com/olegp/common-node#readme

Here are the graphs: http://www.slideshare.net/olegp/server-side-javascript-going...

juliennakache• 14 years ago

Sounds great =D I've never used fibers in Node, but I'm quite experienced with Fibers and EventMachine aka EM-Synchrony. How do Fibers affect 1.debugging & stack trace and 2. performance & garbage collection ? Thx

olegp3• 14 years ago

Debugging is a lot easier since you get meaningful stack traces. Performance is slightly lower due to context switching - check out the Common Node benchmarks I mention in another comment.

Judson• 14 years ago

This project looks really nice, though I really wish there was an easy way to segment routes into multiple files since it seems like an application w/ any kind of complexity would get out of hand quickly.

I didn't see a way by just skimming the docs - is there an easy way?

weixiyen2• 14 years ago

just write a library that traverses a directory and include the files...

furtivefelon2• 14 years ago

this works for me:

include it in routes/index.js, and everything in your routes dir will be exposed if you do var routes = require('./routes')

var files = fs.readdirSync('./routes') files.forEach(function(file){ if(file != 'index.js'){ var exp = require('./'+file); _.extend(exports, exp); } });

maccman5• 14 years ago

Yes, the 'app' global will be available in every file you require in.

Skywing• 14 years ago

Here's an example of my usual pattern, using express: https://github.com/ryancole/node-simple-upload/tree/master/n...

The routes are not namespaced like you'd see with something like Python's Flask does, but it still allows me to group all my similar routes.

weixiyen2• 14 years ago

This looks very promising and is different from the other node.js web frameworks. Very well thought out.

TheBurningOr• 14 years ago

This reminds me of Zappa.js (http://zappajs.org/), one of my favorite CoffeeScript implementations of a web server on Node (although it's mostly just a wrapper for express). I'd be curious, though what advantages there are in creating a totally new web server (this approach) from Zappa's backwards compatible with Express.js's approach.

dreamdu5t• 14 years ago

Regarding coroutines. The very reason Node.js is awesome is because it forces you to do evented programming and makes it apparent what is blocking and what isn't. That's the beauty of Node. The event loop is not a bug, it's a feature. Why program in JavaScript if you don't want to do evented programming? Why use Node.js if you don't want to see the difference between blocking and non-blocking code?

On the flip-side: This looks like a solid implementation of what lots of people have been waiting for (fibers in node).

maccman5• 14 years ago

This is evented programming. The event loop is still being used. Fibers give the impression the code is synchronous, but it's still asynchronous behind the scenes.

jimmyjazz14• 14 years ago

Coroutines don't make the code any less asynchronous it just helps abstract away that detail.

jerf• 14 years ago

"Why use Node.js if you don't want to see the difference between blocking and non-blocking code?"

This is a persistent fallacy in the Node community, but there is nothing that requires a "sleep(1000)" in a language to block all execution in other contexts in that language. That is a weakness of your chosen base language, not an immutable truth. Better languages have been doing this for many years now.

I actually sort of agree with you, but you've got it backwards; if you're going to program in a reasonable paradigm instead of manually chopping your code up to suit a weak language and weak runtime, why not use a language actually meant to do this? "Fibers" (as they are termed here) are the right way to go, but they should be designed in from the beginning, not layered on the fourth or fifth layer of the code. You'll never really be able to get them right up there, because they belong much lower.

scriby3• 14 years ago

This appears only to support one-at-a-time synchronous control flow. Giving up parallel tasks is a funny proposition in node, as it's one of its greatest strengths. So this framework still seems limited in the potential uses, but maybe it will grow over time.

I wrote a library based on fibers that can provide similar benefits to any node application. It also gives simple patterns for error handling, makes debugging easier by maintaining stack traces across async boundaries, and provides really easy ways to do series and parallel flow control.

Take a look at https://github.com/scriby/asyncblock.

It would actually be pretty cool to integrate asyncblock into this project as it could provide the flow control portion for free.

maccman5• 14 years ago

No, this still supports parallel tasks and evented programing. Fibers let you program in a synchronous manner, but it still be asynchronous behind the scenes.

scriby3• 14 years ago

I'm saying the framework doesn't have support for parallel tasks within a single request. For example, the case of kicking off two database queries in parallel, then doing something when both are finished. I understand that each request executes in parallel.

It's possible I missed how the framework supports parallel tasks, can you explain? The only thing I saw was wait(), which gives you "series" instead of "parallel". It's true people could still use callbacks/libraries to implement parallel tasks, but then we haven't gained much.

tjholowaychuk2• 14 years ago

also don't forget v8 stack sizes, this isn't erlang, we don't have super light-weight stacks for coros

shtylman• 14 years ago

I still don't see the draw of using coffeescript server side. Why bother using the language (javascript on node.js) if you are just gonna turn it into something else? Wouldn't ruby suit your needs better?

To some degree I kinda feel like many shops are doing it just so they can say they use node. Maybe that isn't the case.

eurleif• 14 years ago

There's a benefit to running the same language on the client and the server, even if that language isn't JavaScript.

aslakhellesoy• 14 years ago

Looks very similar to connect and express. Can anyone explain how this is different/better?

latch2• 14 years ago

The use of node-fibers is how it's different. Up to you on whether or not you think that makes it better.

NickKampe• 14 years ago

If you have to use synchronous code in JavaScript you're doing it wrong.

latch2• 14 years ago

I'm not saying I like it, but this isn't synchronous code, which I think the readme does a pretty good job of explaining.

jgchristopher• 14 years ago

This is pretty cool. I personally like comb's executeInOrder http://pollenware.github.com/comb/symbols/comb.html#.execute...

potomak• 14 years ago

I think it's much more similar to Goliath than to Sinatra.

olegp3• 14 years ago

Alex, nice to see you working with fibers.

I've recently ported Stick from RingoJS to Common Node. It seems to be similar to Ace (also using fibers etc.): https://github.com/olegp/stick

In fact, some of the libraries I've made to work with it, like mongo-sync (https://github.com/olegp/mongo-sync), should work with Ace as is.

HerroRygar• 14 years ago

Quoted from the documentation: "Every request is wrapped in a Node Fiber".

So...essentially, this behaves like a traditional web server? A process listens for incoming connections, then spins up a new process/thread/fiber to handle the request?

maccman5• 14 years ago

No - a Fiber is completely different to a process/thread. The server is still evented. https://github.com/laverdet/node-fibers

tjholowaychuk2• 14 years ago

each "fiber" still consumes a relatively large stack, so in effect you're right

Ace - Sinatra for Node with Fibers

Related Stories