Ok, the purpose of this article is to give you some insights on how to really make use of SignalR and the server side push functionality it offers. Now, to be honest, yes there ARE many code examples out there, however most of them kind of build on the "let's write a chat application!" approach, which is not that very useful in everyday programming.
Where I have found usage of SignalR is instead in lenghty processes rather than a way of having multiple webbrowser sessions communicate with each others. Very much the same concepts, yes - but I hope this example still eases the understanding of SignalR.
Pushing data from server to client is the key - and I certainly appriciate the elegance in how SignalR (or other similar techniques like pubnub.com) let us accomplish that. One of the patterns I love the most (both as a software and integration architect) is publish/subscribe. And the way SignalR is implemented - to us application developers - it's nothing more than just pubsub! The cool - and inventive - bits of course being able to have the webbrowser session being the subscriber to events.
So this very first example is this:
SignalR Server website (hosted in IIS). Contains a single webpage - hockeyresults. The HockeyResultsController contains two actions, Index and ShowGame
Index: lets the user connect to a certain hockey game (a list of fake live games)
ShowGame: displays live game results and events. Coming from some sort of third party (or maybe manually by someone watching/commenting the game live)
Now some lines of Javascript sets up the subscription (I want to subscribe to all events concerning the particular game ID - yes this is the SignalR GROUP) - and when there is new events for this game it is supposed to be added to the webpage.
Ok, server side: there is a small console application. PushResults.exe.
Call it like this, two parameters - first a game number - then the news text to be published
>PushResults.exe 12345 "Malkin scored his third goal against Rangers..."
The console app will simply call a WebAPI function (downloading http://localhost:17872/PushGameData/SendMessage?gameid={0}&message={1} ) from the SignalR Server website. Thereby handling it over to the website - since that's where the SignalR server is hosted - and where the subscription database is.
Note: I implemented it as a regular controller - my point is just to show an EASY way of interacting with the SignalR server...
As you can see, no magic at all! Point being - input (publishing data) is coming from completely different sources than another webbrowser session.
What really makes this cool is when you, as I said, have for example lenghty third party integrations. Initiate from webbrowser client (which also means set up a subscription to get result whenever available) . Put request into queue/bus whatever. Persist. When data comes back we both store it into persistant storage and sends it back to client browser. In case the user has closed his browser - this way result can be made available to the user next time.
I will make more posts on this theme - as I would like to show you some real example on how to tie state (lengthy process results) to a persistant storage. And utilize queues to fork actual work to dedicated worker processes.
GET THE SOURCECODE (GitHib)
https://github.com/aspcodenet/SignalR1