SignalR in practice 1

by Stefan Holmberg1. January 2013 16:18

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

 

Another restart of this blog

by Stefan Holmberg31. December 2012 16:00

Ok back again...New year, new expectations, new goals...And on a new server as well...

 

Looking for aspcode.net content? Sorry...I have removed everything and redirecting the domain to this site instead...Why?

About 13 years ago I created the site ASPCode.net and while I had a blast with it, I felt the domain name "aspcode" did put some  contraints on me and the content (also the site structure turned into a mess...I mean mixing articles like "Read a textfile with classic ASP" and newer stuff like CQRS/architecture/continous integration etc ).

 

Back then a website typically was just that - a website. You had some ASP/ASP.NET pages, most often just showing some data from a database backend...Today the web platform (.NET) is SO much more than just the website. There are so many more type of endpoints than the basic html over http - MSMQ/JSON (Web API)/websockets (SignalR) etc, and I wanna start over completely with my blog being able to cover these areas without the old luggage.

So - Happy New Years and hopefully I'll start posting some real articles pretty soon!

Tags:

Blog

About the author

 

Proud of being a geek

Month List

Page List