SignalR - great for Developers but not so great for Production?

SignalR - great for Developers but not so great for Production?

recently I've been talking to a few folks about using SignalR for realtime messaging.

SignalR is basically a library that tries to hide the complexity of providing an efficient real-time connection between a client and a server side host.

Here is a more official description of SignalR:

NET SignalR. ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications.
source: http://signalr.net/

SignalR - great for developers...

SignalR seems great for developers, as it covers various use cases such as:

• newer 'evergreen' browsers that support Web Sockets (the top tier of clients)
• older browsers that do not support Web Sockets, but support long polling
• even older browsers that do not support long polling -> SignalR can switch down to plain old client side polling
• SignalR also covers various client Operating Systems (Windows 7, Windows 8 etc.)

SignalR - happy times in Production...

Once SignalR is used in Production, as long as everything runs smoothly, then SignalR is a great tool, handling the different client browsers and OSs.


SignalR - not-so-happy times in Production...

However, as always happens on a busy live system, things will sometimes go wrong, in particular:

• some clients have a different setup (browser or plugins or network connection etc.)

-> we need to support/investigate for such clients

• the system as a whole may have a performance problem that needs to be investigated.

-> we need to investigate and understand the system as a whole (all clients, all servers)

It is in these not-so-happy-testing cases where the one-size-fits-all approach of SignalR can be a double edged sword.


reasons for not going with SignalR
Some folks I spoke with had to abandon using SignalR.

The reasons they gave were:

• Complexity
• Data arrives unpredictably
• Reason for data not arriving can be uncertain/complex
• There is no data
• A network error occurred
• Some other error
• Old browsers
• older browsers behave differently (as opposed to always using plain old client side polling)

• Connection needs to be maintained
• If client disconnects then there is an overhead of reconnecting
• Overhead of reconnecting can outweigh the benefit of SignalR
• Especially true with mobiles/tablets
• Recommend: for mobiles, use simple AJAX calls

• Harder to support
• Different clients will behave differently
• Behavior depends on client OS + browser
• More difficult to understand why an individual client is not working/performing
• More difficult to understand how the system as a whole is behaving/performing
• example: 80% of your users have Windows 8 and Chrome -> Web Sockets but remaining 20% of your users are falling back to long polling or simple polling etc.
• the sample application for SignalR is a very trivial, non-business-critical application (a noddy space invaders style game).

It seems that for some folk, the benefits of SignalR were not worth it …

Alternative approach: KISS...
An alternative approach to real-time communications:

• keep it as simple as possible (KISS...)
• use pure AJAX calls:
• especially for mobile (avoids overhead of reconnecting)
• makes behavior more predictable (data every N seconds)
• aggregate calls, to share data between UI components
• client should be smart
• know what data to ask for (example: only ask for changed data …)
• only refresh/redraw what has changed.
• make client thicker -> allows for further optimizations

Hope this helps...
Hopefully the above is not too critical or negative of SignalR or the folks who have created it...
By all means try SignalR for yourself and decide if it makes sense for you.

Hopefully this article may help people to 'look before you leap', and make an informed choice, as when trying any new technology ...