I know that many of my readers are .NET guys and a core constituency actively hate JavaScript so bear with me and let’s talk about NodeJS for a minute.
Just to be clear, I am not advocating anything by this post. What I think is important is that as you mature as a developer that you look at whatever is happening in the community and be open to why something is new and what new ideas are being proffered by the new technology. My hope is that this post will show some of that.
What is NodeJS?
Simply put, NodeJS is a runtime for JavaScript that encourages non-blocking I/O and fast networking. NodeJS itself isn’t written in JavaScript but it executes JavaScript using Chrome’s V8 engine. It is the engine that powers a lot of cool tools these days (e.g. Bower, GruntJS, etc.) but is primarily used as simple web server platform.
Is NodeJS Magically Scalable?
When I first heard about NodeJS, the comments were always about how you could create fast, scalable web sites/apps with it. While this is true, it’s nature isn’t magic. The trick here is that NodeJS encourages non-blocking behaviors. NodeJS itself is single threaded (though you can run multiple instances of it) but it encourages you to think in terms of events and callbacks. The thread isn’t busy while waiting for these callbacks so it can accommodate a lot more traffic than a traditional web server (e.g. IIS or Apache) per thread.
While NodeJS is an admirable technology, I think it’s real benefit is that it doesn’t rely on thread pools to achieve smart asynchrony. It encourages writing asynchronous code on the server. And if the request is waiting for an operation, it can release the thread to serve another request.
This means you can build better scalability, easier with NodeJS – per thread. Full throughput of NodeJS isn’t necessarily more than you’d get from IIS or Apache, but that’s because they can throw more threads at the problem. NodeJS out of the box doesn’t have the concept of scaling out as an obvious switch. Instead, it relies on that being applied to it separately. There are solutions for this, but it is something that you’d seek out or ‘buy’ (e.g. Azure, AWS, etc.)
What Can .NET Learn from NodeJS?
As far as I can tell (and I am ankle deep into a lot of these technologies), I think .NET is learning from NodeJS. That’s what a lot of the OWIN stuff is about. Combining OWIN and scriptcs gets you pretty close to the vision for NodeJS on .NET. But as a developer, what can you learn?
If you’re like me, you have a lot of skills and experience with ASP.NET (et al.) and I’d love to achieve some of the benefits of NodeJS. One of the concepts you should think about is non-blocking I/O and event callbacks. Much of this is accomplished with Asynchronous Controllers in ASP.NET MVC and Web API. Often developers won’t both worrying about asynchrony here unless they’re doing something that takes a lot of time (like calling out to another web server or calling a database), but I think that you should be thinking about asynchrony every time you make a call that takes any time. The Windows team started thinking like this for WinRT in that any call that is > 50ms requires you to call it via an asynchronous API. The C# async stuff makes this pretty easy so we in web development land should treat it the same way. Most Controllers should be Asynchronous as far as I am concerned. Especially now that EF6 supports asynchronous queries.
Should You Be Looking at NodeJS?
Yes.
Ok, maybe more is useful. I think you should be looking at NodeJS to understand it’s philosophy. You may find for certain types of projects (e.g. APIs or networking projects) that NodeJS is a great model and you should deploy NodeJS project. But at a minimum I think programming NodeJS will teach you how to think in terms of non-blocking I/O. That’s a great skill to have regardless of how you build software.
