SignalR is a pretty interesting technology. It's primary use-case is really about push notifications from your server to your clients. This can be leveraged to do all sorts of cool things like message broadcasts and returning results to the client in a truly asynchronous manner. What I propose however, is that SignalR can be used instead of traditional your traditional AJAX calls.

I've spent quite a bit of time trying to figure out the best way to deal with data transport to and from the browser in a manageable, traceable, and consistent way. I looked at a variety of technologies to help out here:

WebAPI: This could also be standard MVC controllers, but essentially you have control over how your endpoints are structured, you can control serialization, and a variety of other things. This is really the standard technology in the Microsoft world for standing up RESTful endpoints. Again, this is just on the server, so you need to look elsewhere if you want help managing things on the client.

JSend: This is a standardized structure that you should wrap all of your AJAX responses in to give you a consistent way to handle results and error messages.

Vanilla JavaScript: You can make AJAX calls on your client to any server endpoint. It's up to you to manage everything.

jQuery: This provides some syntactic sugar for your AJAX calls, but you're still on your own to manage the endpoints themselves.

Amplify: This is a library built on top of jQuery that allows you to define all of your endpoints in a centralized place. This is a huge step forward since it minimizes the maintenance associated with URL management, query strings, and more.

Before I decided to try SignalR, I was using WebAPI and Amplify with JSend wrappers. This was good, but there was still more manual upkeep that I'd prefer.

Now, take a moment and imagine a world where:

you can define RESTful (or at least RESTful-esque) endpoints on your server
your client magically knows about all of your server endpoints
your client-server programming model is more like remote procedure calls
your JavaScript files have complete IntelliSense for your server endpoints
you never have to maintain any URLs for your server calls
you never have to deal with (de)serialization on the client or the server
your server can push notifications to your client
your client can make synchronous or asynchronous calls to your server
your client and server will automatically figure out the best way to talk to each other

Sound good? That's what SignalR can do for you; if you only think about SignalR as a persistent connection, then you're missing out on a ton of the benefits.

What's all of this look like? If you're just using it as a replacement for WebAPI, it's actually pretty close; you could easily grab your WebAPI code and tweak it into a SignalR Hub. On the client is where you really see a difference. I'll leave you with a code snippet:

var person;

//SignalR (with full IntelliSense)
person = connection.personHub.server.getPerson(1);

//jQuery
$.ajax({
  url: '/api/person',
  type: 'GET',
  success: function (data, textStatus, jqXHR) {
    person = data;
  },
  error: function (data, textStatus, errorThrown) {
    //Handle error
  },
  contentType: "application/json",
  data: JSON.stringify({ personId: 1 })
});

On a final note, please keep in mind that I'm using this to build a large business application that requires users to log in before they can do anything. I certainly wouldn't recommend SignalR for a public site with millions of concurrent visitors, but for a business application that only deals with thousands of users, it's a technology choice that can give your developers a significant productivity boost.