I know its on Github, but a hosted demo would've been nice.
I finally understood what backbone.js is. Seen posts all over HN not knowing what it is. Guess i had to understand what MVC is first(!) . Can you tell im new to programming? ;-)
One Core i7 box with 8GB ram and a second database slave (for replication) with only 1GB of ram. I was running node.js, mongodb and redis all on the same box. I believe it could have handled a lot more, because it wasn't really breaking a sweat on CPU or memory usage, and my dataset was small enough to fit into memory.
Perhaps "scaled" was the wrong word, as I wasn't using multiple nodes horizontally, but you'd only have to add more database servers to scale as the load contribution of node.js was absolutely tiny.
If you were doing huge numbers you could probably also put a load balancer in front of a couple node.js application servers, each connecting to the same mongodb replica set (which you could easily scale by just throwing in more nodes). But if you're doing an app like this one, you couldn't use nginx as a load balancer because it won't proxy WebSockets.
Chat app could easily kill a server just a few years ago, at least using the "default" technology available for the mass. Now there are many solutions to write a scalable chat application. This is definitely a good point :)
> Yes, you read correctly. JavaScript on the server. Weird huh? That’s what I thought.
Really? It wasn't so odd back in 1996 when the Netscape web server supported it. To be sure, V8 and node have wildly better performance characteristics..but the idea of js on the server isn't exactly new: http://en.wikipedia.org/wiki/Server-side_JavaScript.
Just curious, how well did your card game scale? How many concurrent users could it handle? And could you easily balance the load by firing up more servers if you needed to?
The reason I ask is that everything sounds all good on paper, but how scalable is this "stack" in the real world. Would it be more scalable than relying on an xmpp network (which can be scaled wide if need be)?
I like the idea of transport transparency on the client, yet very much unlike the idea of writing JavaScript on the server.
I've never tried node.js but I'm very curious to know what it offers that, say, Twisted or .NET or any other framework with proper IO facilities doesn't.
Quick survey: if you could have the equivalent of this stack, with persistence, as a service, would that be interesting to you?
It would be RESTful relational database-as-a-service but where any individual item could show updates in real time. (E.g. real-time chat would just be a Javascript component.)
30 comments
[ 2.5 ms ] story [ 40.7 ms ] threadEr, no, actually. Quick, someone sharper than I help me out!
that's what he did there
Perhaps "scaled" was the wrong word, as I wasn't using multiple nodes horizontally, but you'd only have to add more database servers to scale as the load contribution of node.js was absolutely tiny.
If you were doing huge numbers you could probably also put a load balancer in front of a couple node.js application servers, each connecting to the same mongodb replica set (which you could easily scale by just throwing in more nodes). But if you're doing an app like this one, you couldn't use nginx as a load balancer because it won't proxy WebSockets.
http://www.javarants.com/suba/html/visualj++.htm
Really? It wasn't so odd back in 1996 when the Netscape web server supported it. To be sure, V8 and node have wildly better performance characteristics..but the idea of js on the server isn't exactly new: http://en.wikipedia.org/wiki/Server-side_JavaScript.
The source is unobfuscated, so you can check it out if you want.
[1] http://apps.facebook.com/alloutcricket/
The reason I ask is that everything sounds all good on paper, but how scalable is this "stack" in the real world. Would it be more scalable than relying on an xmpp network (which can be scaled wide if need be)?
http://www.hubabl.com
I've never tried node.js but I'm very curious to know what it offers that, say, Twisted or .NET or any other framework with proper IO facilities doesn't.
It would be RESTful relational database-as-a-service but where any individual item could show updates in real time. (E.g. real-time chat would just be a Javascript component.)