Node.js er what’s it supposed to be used for?

<Disclaimer I am new to Node.js so this represents my current thoughts and additionally much of my development is on a Microsoft platform so I come from this perspective>

There is a lot of fuss in the web development community at the moment about Node.js and how it’s going to be the next big thing.

Node.js provides an environment to run JavaScript in and has been used successfully on a number of high traffic sites such as LinkedIn so I decided to investigate further. Now I really like JavaScript (although it has both the irritation and bonus that I discover something new about it every week) so I was keen to look into this technology and what I could potentially use it for.

The main arguments I have heard for using Node are:

  • It’s great for service type stuff as it’s more scalable because of its eventing model, no locks etc
  • A JavaScript runtime environment outside the web browser

Superior Scalability

One of the biggest claims you will hear from Node advocates is its superior scalability due to its use of call-backs (async) and no locking. The jury seems to be out on whether Node applications do actually scale better than other alternatives and there are countless blog posts arguing both ways. I don’t know enough about the low level detail to argue either way but let’s assume it’s pretty quick for certain scenarios (basically anything that’s IO bound is a potential candidate).

It’s important to also note that you can develop a similar scalable async model with .net although it certainly wasn’t as easy or intuitive as Node.js (especially without C#5’s Async features).

One thing I will say however in that my consultancy experience it is rarely the technology that is at fault when it comes to performance and let’s face it most of us don’t need our applications to be as scalable as something like LinkedIn or Facebook. More often than not performance issues are due to many calls being made to a database (usually multiple times) and the returning unnecessary data so I am not convinced as to this being a good enough reason to try out Node.

A way to run JavaScript outside the web browser

Node.js is pretty cool for playing around with JavaScript providing an environment for running your JavaScript applications and even a RPL interface. I came across an example of this last week when playing with the excellent CSSLint that used Node.js to tell me all the stuff I had screwed up when writing my CSS.

I was however left with the question of why I would actually want to write an application in JavaScript as there are so many existing (and easier?) ways of writing applications. If I want to knock off a quick prog to automate a tedious task or do something similar to CSSLint I am probably going to do it in C# with a mature set of well documented & maintained APIs and Visual Studio’s nice debugging environment. Of course JavaScript’s functional qualities make it very elegant for certain tasks and I can see there might be developers who only know JavaScript who now have another platform to develop on.

The issue however is that the very experienced JavaScript developers tend to have gained this experience from front end work so may not be the sort of people you want developing your services. But I guess its pretty cool that it opens up another option for JavaScript developers.

The second issue that bothered me was due to Node’s immaturity – would it have many libraries for tasks such as querying a database? Well I need not have worried as Node.js has a large community and a number of extensions (node packages) have been developed for performing common tasks so this shouldn’t be that much of an issue. I’m not sure I would trust a community developed interface to a product such as SQL Server to be as mature & up to date as Microsoft’s versions through.

Below are the main advantages I can see Node.js offers

Advantages:

  • Potentially more scalable for certain tasks
  • Developing certain types of services could be more intuitive
  • Node.js servuces are light weight and easy to modify
  • Anything has to be better than WCF (sorry Himanshu but WCF was written by the devil)
  • JavaScript is becoming a universal language & you can potentially run your code on multiple platforms
  • IISNode makes Node.js very easy to setup on Microsoft platform and benefit from IIS features such as logging, connections etc
  • Large number of packages/extensions available
  • Node.js apps can be hosted very cheaply compared to an MS based app e.g. Heroku
  • For the MS devs Node.js can be hosted on Azure (although its apparently a bit of a pain)
  • Could help progress JavaScripts development and standards e.g. common.js

Disadvantages:

  • How many apps actually need Nodes much touted scalability?
  • When used for Service development the devs that are experienced in writing service type code probably aren’t also those experienced in JavaScript (not always of course!)
  • How can a wrapper for something like SQL server be more efficient and feature rich than Microsofts implementations so any perf gains may be negated by usage of poor performing extensions
  • Packages may not be maintained aren’t as mature as traditional vendor options
  • Poor debugging experience (I understand there is a debugger browser extension available)
  • Immature technology – potential bugs and lack of devs skilled in this area
  • Can same “perf/scalability gains” be experienced with existing async functionality?

I’d love to have a really good solid reason to use Node.js but having spoken to a number of colleagues no one is yet to give me one.

Sure its cool but I am left with the question what are you actually going to use it for? Er..

I remain open minded and I’d love for someone to give me a good answer to this question 🙂

Advertisements

4 thoughts on “Node.js er what’s it supposed to be used for?

  1. I’ve got several points of which I think are worth pondering from your post.

    You say that you’re concerned about using a non-MS project to communicate with something like SQL server as you’d expect a Microsoft offering to be more efficient and feature rich. How is that different than saying you should use EF over NHibernate because NH is an OSS product so how can it be as feature rich?

    Azure deployment is actually quite simple, the pain is the Azure spin-up time (as usual).

    Packages not being maintained is a problem on every technology stack, I’m sure if you look closely at the MS stack you’ll see plenty of packages rise and fall. And take what happened with gRaphael last year, since the developer of Raphael didn’t want to maintain it he wanted to kill it, does that make you concerned about browser-based JS libraries?

    The debugging experience of every platform other than .NET suck, MS has really done an awesome job with that. But that said Node.js does have a very easy-to-use debugging experience.

    Lastly you say that none of your colleagues have been able to give you a good reason as to why it’s a viable platform; could that be more related to the kinds of people you’re asking? Selling Node.js to a bunch of .NET devs is probably not really going to work, .NET *is* a great platform, it does have great reasons to use it. So why should they go to a reasonably unproven platform? There probably isn’t a great justification for the majority of projects which .NET is undertaken on. It comes down to the right technology for the solution, no one technology is right for all.

  2. Thanks for the reply Aaron.

    OSS projects can of course be as feature rich as vendor solution – indeed in your example I don’t think it would be controversial to suggest that Nhibernate is very much more feature rich than Entity framework..

    My point is that if I want to talk to SQL server from Node then I have to do it via a node compatible wrapper. If I want to do this in say ASP.net this is very easy via the framework classes and I (and my colleagues) are very experienced using it.

    The developed wrapper cant be as stable as using stuff like the very mature System.Data.SqlClient clients or a mature OSS project such as Nhibernate (which I cant use in Node unless someone has built a wrapper for it – I would imagine Nhibernate underneath uses the .net SQL libraries so I now need two wrappers e.g. an Nhibernate wrapper + an ADO.net wrapper?). Would all these abstractions also negate some of Node’s performance benefits?

    Anyway SQL is one example and Node.js certainly wasn’t built with this in mind and maybe is more suitable for other functions?

    I take your point on the packages being maintained and of course Microsoft are guilty of frequently changing directions. I dont worry about using JavaScript browser based libraries as they are easy to maintain and modify and generally are limited in scope.

    However lets go back to our SQL example – developing a wrapper for ADO.net APIs isn’t trivial and I understand this kind of thing has to be done in C++ in Node (you can of course write classes in JavaScript but not for this kind of task to the extent of my knowledge). A separate C++ extension with JS wrapper sounds a lot harder for me to maintain/modify.

    Relying on framework classes or a mature open source project such as Nhibernate seems a lot less risky for a project long term than one of relying on a node package to be maintained. Additionally using these within Node adds an additional hill to climb.

    I haven’t tried Azure and Node yet so I will reserve judgement 🙂 (I am sure like everything Azure related it works seamlessly cough!)

    Your point about selling Node to .net devs is fair and maybe its not the target audience. My post is of course written from my own perspective (as a .net dev) where I try to see how I could use it and for the clients I am likely to work with.

    Maybe you could describe a few scenarios for where you think Node.js would be appropriate?

  3. Real-time communication is an example where I think Node.js is the best out there for it. The .NET solution (Jabbr) is still very immature. Real-time communication is becoming more important for web applications, either via long polling or web sockets.

    RESTful interfaces, being so close to the HTTP stack it’s very easy to produce a series of URLs which exposes a RESTful API to the web. IMO this is easier to do than with MVC (and I’ll admit I don’t really know what the new WebAPI stuff is like, that might make it easier).

    Anything you’re doing with MVC, provided you’re doing MVC smart (ie – the controllers are just dumb pass throughs for HTTP to a service layer), as the routing is really all that the app has to handle. Express.js is really powerful in the way it can do routing, and it’s a bit easier (IMO) than doing the same with ASP.NET MVC.

  4. I can see your point regarding real time communication. Node’s development experience for this does seem more intuitive and you could knock something up pretty easily. SignalR looks very promising but it is still early days.

    Real time communication (at present) does seem a bit of an edge case through and it’s not the sort of thing that you need to do everyday – although it’s not too hard to see a need for this becoming much more common especially once web sockets is supported in the next version of the big blue E.

    I think when developing REST services using something like Express.js would probably involve less code and as one of our colleagues found last week MVC can sometimes get in the way when you want full control over http.

Comments are closed.