Best way to do async programming with Asp.Net

Question

There seems to be several options available at the moment to do async/push-style programming with asp.net. But I'm a little confused as to what is the best and what offers the most developer friendly approach. Things I've already come across are,

NodeJs

SignalR

Using PushStreamContent (Web API) and something like KnockoutJS

Though SignalR is deemed to make it to asp.net 4.5, I see a lot of interest on NodeJs within MS (Specially around Azure). Can anyone shed some light on the differences (of at least NodeJs and SignalR) ?

Answer 1

SignalR is "a client and server side library for .NET that provides messaging and an abstraction over a persistent connection." This doesn't magically make your code async - it just allows your server to call clients (including JavaScript running in your users' browsers) asynchronously.

However, C# 5.0 which ships in .NET 4.5 & Visual Studio 2012 (as well as in Mono 2.11+) allows you to write/modify code to be async through the use of the new async & await keywords.

If you're already a .NET developer, C# async & await and SignalR are very easy to pick-up, learn and run, allowing you to build highly scalable, very high performance systems.

Node.js enables you to write your code in JavaScript and host it in an app server.

Node is getting a lot of attention at the moment but if you're coming from a .NET development background, it's worth noting some of the things that may surprise/annoy you when moving to JavaScript on the server:

1. JavaScript is a very powerful and extremely flexible dynamically typed language. However, this flexibility can be very dangerous and problematic until you've learned its many flaws and how to overcome them. If you MUST execute JavaScript code, consider writing your source in languages like TypeScript and CoffeeScript which compile down to JavaScript but insulate you from a lot of JavaScript's dangers.

2. While node offers great async dispatch capabilities, its code-execution performance can be FAR slower than executing C#. If your code does little/no processing of data, you may not notice this issue. If, however, your code does a fair amount of data-processing / calculations / analysis / etc., you may find node's JavaScript performance-hit unacceptable.

3. Node is single-threaded! If your code has to perform some heavy processing, for example, performing a complex calculation over a large amount of data, it'll prevent a single node instance from serving other incoming requests until each processing operation is complete. Thus, you will need to plan on enabling node clustering (currently an experimental feature) or, if you host node on Windows, use IIS & IISNode]4 which handles node instance management using the (awesome) IIS & Windows Process Activation infrastructure.

4. Compared to the typical .NET developer's debugging experience, debugging code running under node is a slow and cumbersome process right now. To do so requires you to use node-inspector and Chrome web browser to debug the code, but the experience is poor: Breakpoints aren't preserved across runs; conditional breakpoints are not supported; the displayed call stack is shallow; etc.