Copyright © LucasFilm

SignalR with Gulp+Browserify

Never tell me the odds.

Useful webdev post or gratuitous Star Wars clickbait? The Empire hates him!

SignalR enables real-time communication between Web clients. Modern browsers use WebSockets, and SignalR allows connected clients to call server methods (as well as server-to-client RPCs) with a clever hub/proxy architecture.

The demo apps for ASP.NET SignalR provide a good foundation for learning this neat little library. In Visual Studio 2013+, when one adds a SignalR 2.0 hub class, we get a /Scripts folder with some jQuery files. These allow developers to use a familiar framework for creating client side code that interacts with the hub. In this post, I use the gulp task runner and browserify js module tool to package the required libraries and my application code into one file.

As always, you should know I learn as I go and struggle every day. This was a fun, if not contrived, exercise.

The App

This is what the user sees while the WebSocket connection is resolving and the server is returning data.

Quite simply, the client receives a JSON string, which it parses and renders the response text, while adding a URL to an anchor tag’s href attribute:

The complete solution is on GitHub. You can clone the repo on your machine and open the project in Visual Studio 2013 or higher running .NET 4.5.

As I mentioned, once I added the SignalR Hub class, Visual Studio created a /Scripts folder with the following:

The jQuery SignalR plugin creates wrappers for the connection object’s proxy and allows us to use promises when calling server methods. As you might expect, it depends on the jQuery library.

What’s the big deal? The following image is the markup for a SignalR demo on Microsoft’s web site:

And here is ours:

I am not simply bundling scripts; browserify allows developers to define modules for client-side JavaScript — we can require these components much like using directives in C#.

This is our app.js file:

Our jQuery dependency is resolved through browserify’s “global” object. The require(“signalr”) statement tells browserify to include the SignalR jQuery plugin in the final script.

“sbHub” is the reference to our SignalR hub class. Note the camelCase convention — SignalR expects client code to refer to hubs in this manner.

jQuery can be grabbed via npm and required into our app, but the SignalR core plugin cannot be redefined as a module and must be used as-is by our client code. In our package.json file, the browser field creates an alias for the .js file, which can then be inserted into the transpiled output:

"browser": { 
  "signalr": "./jquery.signalR-2.1.2.js" 
}

Copyright © The LEGO Group

The Build

We have an app.js that has some strange statements, a package.json file with our dependencies, and the desire to trudge along.

If you want to run the tasks in gulpfile.js, fire up your console from the /Scripts directory and run

npm install

Then,

gulp

Here is my output (in my fave console):

Gulp takes the source app.js, streams it into browserify (which handles all the require’s), gulp-uglify packs it and saves a new app.js in the /Scripts/dist directory. Full credit goes to @sogko for this post.

That’s it! Run the app in Visual Studio or in your local IIS. I didn’t include things like gulp-watch or serve-static because I wanted a balance between Visual Studio and console tools. Though I will share one thing that drove me crazy due to authoring in VS2013 and subsequently packing in Gulp:

Encoding is a real mindfuck. Saving in UTF-8 helped. Tell the kids.

Conclusion

Don’t everyone thank me at once.

SignalR is a good thing for ASP.NET. It is a lightweight, intuitive extension of familiar technologies that were historically not trivial to implement in production environments. Similarly, tools like Gulp and Browserify simplify our front-end workflows and make our code coherent and modular. I enjoyed learning and writing about them and I hope you will too.

Your struggling friend,

@foobarjs