/SignalR-Demo

SignalR demo for DevSession

Primary LanguageCSS

#SignalR DevSession, 2014-07-30

This repo contains demo code and PowerPoint slides for my DevSession on SignalR. The code was partly built on the "ASP.NET MVC5 with Bootstrap 3.1.1 LESS" template available online, and contains a few drop-ins, including:

  • Angular.js
  • Twitter Bootstrap
  • LESS
  • A small MVC5 REST API

There are two main demo apps: Blocks and Feeds.

  • Blocks is a simple real-time block-dragging app implemented in both the Hub and Persistent Connection styles.
  • Feeds is a more involved application that simulates multiple users posting to the same feed at once. It uses Angular, Bootstrap, LESS, and wraps SignalR in a familiar jQuery-style event-handling pattern.

This repo contains demo code and PowerPoint slides for my DevSession on SignalR. The code was partly built on the "ASP.NET MVC5 with Bootstrap 3.1.1 LESS" template available online, and contains a few drop-ins, including:

  • Angular.js
  • Twitter Bootstrap
  • LESS
  • A small MVC5 REST API

#Presentation Notes

Below are my presentation notes, which closely follow the slides.

##Options for async messaging

  • AJAX
    • Request/response model
    • Usually means interval polling
      • High overhead in cycles and bandwidth
      • High latency
      • Wasted calls if there's nothing to transmit
    • Lots of code, coupling, overhead
  • JSON via Web API/REST
    • Less overhead
    • Request/response model
    • Still doesn't solve polling issue
  • WebSockets
    • Direct connection between client and server
    • Uses long polling to keep connections alive
      • Connection stays open until it times out
      • Less overhead than interval-polling

##Enter SignalR

  • Pub/sub model instead of request/response
  • Uses WebSockets, which means long polling
    • Degrades gracefully to HTTP in older browsers
  • Small, dynamic code
    • Advantages for RAD
  • Loose coupling
  • Automagically serializes to/from JSON
  • Built on top of OWIN
  • Allows grouping of connections/users
  • Support for web, iOS, Android, C#, and other clients

##SignalR setup: It's fast and easy

  • Server side
    • Pull down SignalR from NuGet
    • Implement Hub class
  • Client side
    • Open a connection
    • Bind event handlers
    • Start publishing events

##Hub vs Persistent Connection

  • Not many advantages to PC over hub. Use PC in the following circumstances (from documentation):
    • The format of the actual message sent needs to be specified.
    • The developer prefers to work with a messaging and dispatching model rather than a remote invocation model.
    • An existing application that uses a messaging model is being ported to use SignalR.

##Performance

  • Generally good performance compared to other client/server messaging types
  • Allows 5000 concurrent requests per CPU by default
    • Can be configured
  • When request limit exceeded, server starts throttling requests with a queue
  • SignalR team offers SignalR.Crank tool to generate testing load

##Security

  • Initial authentication/authorization as normal
  • Pass connection ID and username back and forth
    • Connection ID is randomly generated and persists for the entire connection
    • Uses encryption and digital signing
  • Protects against Cross-Site Request Forgery (CSRF)
  • Can transport using SSL

##Conclusion: Why care about async?

  • Frees us to innovate
  • Easy adoption
    • Coding is quick and easy
    • Matches our pub/sub pattern
      • Good conceptual fit with NServiceBus
      • Several discussions available about SignalR + NSB, SignalR + eventual consistency, etc.
    • Plays nicely with jQuery, angular, etc.
    • Easy abstraction to jQuery-style events, options for durable messaging

#Links/Further Reading

##Overview

##Implementation, concepts, and tutorials

##Mobile

##NServiceBus, durable messaging, and eventual consistency:

##Performance

##Security