Asynchronous programming and SignalR
This book has no ambition of being an architectural one, and it does not go too deep into technological issues because those would take a lot of space and distract the content from its direct goal of delivering straightforward solutions to common problems. Nevertheless, the fully asynchronous nature of SignalR deserves a couple of words and some reference material for those interested in digging into it.
The trend in programming in the last few years has been pretty clear: asynchronicity rules. Whether you are building a modern and reactive UI, a database-intensive backend, or a distributed system, you want to optimize resources, and the first logical choice to achieve that is avoid holding them if you don't use them. In other words, you never want any code to be stuck waiting for something else, because blocked code does nothing while still holding precious computational power that could be used for good in different ways.
This brings complexity, because it's clearly harder to know when a result is ready if we do not wait for it anymore. Computer scientists have been working on these problems for a long time, but it's just recently that mainstream platforms started supplying programming models more sophisticated than classical callbacks, which do their work fine but inevitably lead to intricate and unreadable code.
Nowadays, we have easy access to several better approaches that allow us to manage asynchronous code better. One of those is the idea of a promise, or future value. This is an object that represents a value that will be ready at some point in the future, and its availability will happen asynchronously with respect to the logical thread of code that has a reference on the promise itself. The great advantage of this model is the fact that promises can be composed, leading to more natural and readable programs that end up looking sequential even if they are totally asynchronous.
JavaScript does not support promises natively, but there are several libraries implementing the pattern. One of those is the jQuery Deferred Object, which we have mentioned here because it's the one used by SignalR. Another quite popular one is the Q library (https://github.com/kriskowal/q).
On the .NET side, the Task API, available since Version 4.0, is an implementation of the promise pattern that allows the usage of the Task-based Asynchronous Pattern (TAP), and the async/await syntax from C# 5.0 greatly simplifies the composition of promises. What's important here is the fact that most of the networking infrastructure available with .NET is fully asynchronous and implements TAP.
SignalR, on the one hand, leverages and embraces such support from the networking infrastructure, and on the other exposes itself the very same way, making sure things are done the most efficient way possible behind the scenes while clients are enforced to do the same by the model. On the server, methods are invoked when corresponding low-level messages become asynchronously available, resulting in a highly scalable messaging framework. On the client, the connection and hub's proxy objects expose methods that return composable promises, leading developers to write clean and efficient code.
This is an incredibly vast topic we just wanted to briefly introduce; you can find a lot of material about it on the Web for your investigations. The following are a few helpful links:
Futures and promises: http://en.wikipedia.org/wiki/Futures_and_promises
jQuery Deferred Object: http://api.jquery.com/category/deferred-object/
Task-based Asynchronous Pattern: http://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
Continuation Passing Style and Asynchrony in C# (blog post series by Eric Lippert):
