Azure Mobile Services & SignalR

Azure Mobile Services

Azure Mobile Services is an Azure Platform-as-a-Service (PaaS) offering for easily authoring a mobile application back-end, complete with support for user authentication, push notifications and more. It is a type of service also commonly known as a Backend-as-a-Service.

ASP.NET SignalR

ASP.NET SignalR is a library for ASP.NET developers that simplifies the process of adding real-time web functionality to applications. Real-time web functionality is the ability to have server code push content to connected clients instantly as it becomes available, rather than having the server wait for a client to request new data.

Putting It Together

Azure Mobile Services has support for SignalR for quite some time, and this blog post describes quite well what are our possibilities as developers, what to expect and how to use it.

Unfortunately, the sample on that blog post provides a .NET C# sample for demonstration purposes and I really wanted to use an HTML based client for my client application with Azure Mobile Services. We should also bear in mind that a web scenario is the main scenario in which we’ll consider using SignalR (other client platforms have dedicated Push Notifications available).

Creating a JavaScript SignalR client working with an Azure Mobile Services back-end is quite straightforward, just like working with any other SignalR enabled server – except for several issues outlined below.

SignalR Client Library Version

This issue is a subtle yet important one. The latest stable SignalR version available today is 2.2.0, which is the version I initially used in my JavaScript client. However, Azure Mobile Services’ back-end SignalR support takes only version 2.1.1 as a dependency we get a version mismatch – versions 2.1.1 & 2.2.0 cannot work with one another, causing the entire thing not to work.

Conclusion – As of the time of writing, in the JavaScript use SignalR client library version 2.1.1.

Client Authentication

Azure Mobile Services integrates SignalR’s security with its native security implementation. In my scenario, I wanted to use an API key to enable SignalR access, however the same principal applies to a “standard” authenticated client. In order to do this we need to tell the SignalR client to send the x-zumo-application authentication header on each request, which can be achieved by the following code:

var headers = {};
headers['x-zumo-application'] = apiKey;
$.signalR.ajaxDefaults.headers = headers;

Connection Transport

As shown above, we need to pass an authentication HTTP header with each request. Unfortunatly, the web socket implementation in browsers (as opposed to other platforms which might implement web sockets) does not support specifying HTTP headers that should go with the request. As a result, the only way to achieve this is by using the Long Poll transport:

$.connection.hub.start({ transport: 'longPolling' }, function () {
    console.log('Hub Started');
});

Note that if you do not need authentication or you are not running in a browser then this is not a limitation in your case.

Get the Code

The entire working code sample is available for download from here. To get the sample working:

1. Create an Azure Mobile Service in your Azure account.
2. Update your mobile service name & API Key in “index.html” & “page.js”.
3. Update your mobile service name in the “Web.config” for the mobile service.
4. Publish the service.
5. Run the HTML client.

Enjoy!