We have some Node.js code (not yet in production) for http://lanyrd.com/ for interacting with the Twitter streaming API.
My personal philosophy with Node.js is to use it for small, standalone network servers that complement the rest of my stack - basically anything that needs to handle large amounts of I/O. Everything I've written with Node.js so far has been just a few hundred lines of code.
So for templating, database interaction and so on I'll keep using Django. I'll use Node for stuff like comet/WebSocket pubsub services, handling file uploads, rate limiting API proxies, webhook dispatching, interacting with slow or streaming external web APIs, etc.
Why is it good to use for large amounts of I/O? I'm in the process of making a twitter-based app and I'm debating whether or not I should be using Python / Django.
The thing I like about node.js is that you can now pretty much write your entire web app in JS, both front end and back end. This really helps with the context switches that happens in larger projects. With mongoDB, you can pretty much use JSON throughout the application stack.
I've used it on a few mid sized personal projects and have to say I generally regret the decision. The last project I worked on in node was great at first but as I slowly started adding more features the code became rather unmaintainable; IO heavy parts became a mess of deeply nested callbacks and compared to say python the choices of third party libraries are limited and often of poor quality. At the end of the day I personally rather use a tool that does not force me to compromise on code quality.
Many of my problems with node are simply a matter of taste and I'm not trying to discourage the use of Node.js; its pretty good for quick and dirty web services but, in my personal experience it has not been worth the trouble for large projects.
Some things are a bit less mature than one might desire, but all in all it's a pretty brilliant piece of technology and I find myself using it more and more.
We are at SelfServeApps and it's awesome. Not only is ES5 a decent language but our stack is incredibly simple (great when you don't have a sysadmin). We install node on a frontend server and run our app, that's it. It talks to our backend (Riak) over http.
edit: We have a thick client using Cappuccino and we talk to our Node web service using JSON. The only templating on the server is for a few HTML emails, password reset page, and the email verification landing page.
Nice! Have been waiting for that since the tragic loss of AppJet. Do you plan to provide some sort of paid hosting in order to prevent going broke due to hosting cost?
Thanks to matthewfl (http://twitter.com/#!/matthewfl) for putting the time in to make this. It's really useful for someone who wants to experiment with node.js.
i'm not sure how these guys did it, but one could do a similar setup. one of the issues to overcome is availability of ports. since most apps will listen on port 80, you can use the HTTP Host header to virtual host instances. a reverse proxy can be set up at nnn.jsapp.us, look up the nnn and get an IP:port of which (internal) node instance to pass the request to. you could internally use UNIX domain sockets so there wouldn't be a need to worry about TCP sockets, but your frontend proxy needs to be smart about this.
thus nnn.jsapp.us can be mapped to a single IP address. things get more tricky if you allow people to host arbitrary TCP servers that aren't reverse-proxy friendly. the jsapp.us implementation seems to ignore a port argument to listen(), which seems reasonable.
the jsapp.us implementation seems to be able to keep multiple node instances running. obviously, if more and more people start hitting the server with their apps, this could lead to resource starvation. they probably have a clever way of not keeping the node instances sitting idle. if a particular nnn.jsapp.us host exists and the node instance isn't up, start it on the first "cold" request to that host. this allows the service to keep only those instances up and running that have had recent requests. or maybe they shut down a user's instances only when they log out or close the editor page?
that's my take on it. someone (maybe the jsapp.us guys?) should put together an all-in-one node.js hosting service that has a nice web-based editor based on Bespin or Cloud9 IDE and integrates node-inspector for an awesome remote debugging experience.
