IMHO, I guess the important thing about writing a server is to handle sockets and a few protocols (HTTP, TCP… stuff like that). Now protocols are (again, IMO) rules of how information should be positioned in a packet so you can do that with pretty much any language. Traditional server technologies like Apache Tomcat, Glassfish… have been spawning threads to handle each incoming request. That’s not necessarily a bad thing but the bottlenecks seem to come down to IO so there’s been drawbacks in terms of blocking threads when u do a long query and such. Now u can overcome that by implementing distributed systems with a load balancer on top, along with some request filtering and routing, at which point it becomes kinda costly.
NodeJS uses Event Queue which puts everything in there and does event loop and uses callback functions. So technically there’re no blocking and the app is very scalable, theoretically. With that said, a long query gets run and once it’s done the callback is invoked. Now that sounds kinda cool.
OK so it can handle HTTP request, what else? Another important thing I would say is the database, which kinda comes down to separate vendor. How does the server connects to the database? Using a driver! Java gets an advantage cause it maintains an interface for vendors to write drivers based on. RoR supports a couple of database technologies and so is Django. There’re enough database vendors and plugins out there that it’s gonna take a while for NodeJS to catch up on that front, I assume.
What else? Some process manipulations like File IO and such, cause apparently the server will need to, at some point, modify some file resources, invoke some processes and stuff like that. NodeJS does have this, although I’m not sure how stable/mature it is. But that should take care of it.
Now I’ve always thought that RoR and Django were booming due to their ability to do rapid prototyping/development really really fast. You can get started on a webapp at a reasonably good pace with those, thanks to ORM and dependency injection and all the fun stuff. Honestly, I’m kinda a purist to a degree that I don’t hate abstracting 1 language over another, but magic can be disastrous sometimes. I believe that I should hand-write SQL queries and HTML/CSS instead of using ORM and compiled HTML (such as erb/jsp/asp…) cause you get a better control over it. It gets hard to manage after a while but it’s easier to identify the bottleneck and optimize it, instead of optimizing RoR and hoping that would optimize SQL.
Besides, using compiled HTML puts more load on the server than client, which in a way provides a more stable outcome since client machines/browsers vary a lot. But again, back to mixed language kinda thing, gotta be careful.
Wait, so what about setTimeout and setInterval and stuff, aren’t they supposed to give a better control? Well FYI, setTimeout to 1000ms doesn’t mean it’ll get executed after 1000ms. It means that’ll get executed after AT LEAST 1000ms (cause it’s a queue…) so yeah, still digging around.
Back to my project which is a CMS now might turn into an RDS, I honestly think all we need are those important features listed above. Worst case is that we write a thin layer of wrapper around the tools we want to use, then invoke shell processes for those. But anw, it comes down to a light, thin server framework cause we probably don’t need all the big guns (which can take tons of time to tune). So yeah, it’d be great to set foot on that!!!