Ace - Sinatra for Node with Fibers
github.com
github.com
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.
Maybe name it "Frank" (Frank Sinatra) or "Ray" (Ray Charles). :-)
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...
On the flip-side: This looks like a solid implementation of what lots of people have been waiting for (fibers in node).
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.
I didn't see a way by just skimming the docs - is there an easy way?
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); } });
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.
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.
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.
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.
The usual CRUD scenario is that you do a DB lookup, then perhaps alter the object, save it to the db, and return to the client. All tasks are performed sequentially. Unless multiple async calls are a common scenario, then I think I'll leave them out. Is there more multiple async examples you can think of?
-Anything dealing with disk I/O like copying or reading files -Sending / receiving from S3 or other file repository -Making a request to external web services as part of a request -Working with document DBs like Mongo where instead of a join you can do one query per table in parallel
I would love it if you could check out asyncblock and see if you like how it helps manage control flow with fibers. It would be easy to integrate with what you have already. We use asyncblock in a very large node based application, and it's really helpful for keeping business logic straightforward and simple.
Another possibility would be using node-sync (https://github.com/0ctave/node-sync) if you prefer their approach.
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?
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.