Generating static files for JavaScript proxies

One of the most fascinating things about SignalR is its ability to generate JavaScript dynamic proxies on the fly for any server-side Hub. These proxies make writing client-side code very easy and natural, but there's a price to pay, because the dynamic endpoint has to generate all the necessary plumbing code on the fly when requested. Although SignalR optimizes this process with caching strategies, this approach cannot be as efficient as a static and cacheable file. For this reason, SignalR's team decided to provide a way to distribute JavaScript dynamic proxies through a statically generated script.

In this recipe, we'll write a very basic application using dynamic proxies, and then we'll rework it to replace the dynamic endpoint with an equivalent static file.

Getting ready

Before writing the code of this recipe, we need to create a new empty web application, which we'll call Recipe33.

How to do it…

Let's quickly build our sample project using the following steps:

  1. We first add a new empty Hub, which we'll call EchoHub, using the SignalR Hub Class (v2) template, as we have already done many times earlier. It will contain a simple method to return a hardcoded message, as shown in the following code:
    using Microsoft.AspNet.SignalR;
using Microsoft.AspNet.SignalR.Hubs;

namespace Recipe33
{
    [HubName("echo")]
    public class EchoHub : Hub
    {
        public string SayHello()
        {
            return "Hello";
        }
    }
}
  2. We then create the Startup class with the appropriate template, containing a basic bootstrap sequence, as follows:
    using Microsoft.Owin;
using Owin;
using Recipe33;

[assembly: OwinStartup(typeof(Startup))]

namespace Recipe33
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR();
        }
    }
}
  3. We finally add an HTML client page called index.html. The code to be added to this page is as follows:
        <script src="Scripts/jquery-2.1.0.js"></script>
    <script src="Scripts/jquery.signalR-2.0.2.js"></script>
    <script src="/signalr/hubs"></script>
    <script>
        $(function() {

            var hub = $.connection.hub,
                echo = $.connection.echo;

            hub.start().done(function() {
                echo.server.sayHello()
                    .done(function(message) {
                        console.log(message);
                    });
                });
        });
    </script>

    In its head section, we'll reference the required JavaScript libraries as usual, and then the dynamic endpoint. We'll also add some trivial code to just prove that the connection is actually working. At this stage, there should not be any need to go through this code in detail, so we'll just list it and move on.

We can test the code we just wrote by launching the application and navigating to the index.html page. The page will just emit a message onto the browser console, displaying what's received from the server-side Hub.

This was simple so far, and as usual we used the /signalr/hubs endpoint, but that's the piece that has to be generated every time the application starts up, with some (although limited) waste of resources and some difficulties to face when dealing with caching. These issues can be easily solved using a utility distributed with SignalR called signalr.exe.

The signalr.exe utility is a simple command-line application that can be used for a few support tasks. It can be used to manage custom performance counters, and it is able to generate a static version of a dynamic endpoint. This is the functionality we're after in this recipe, therefore let's see how and where we can get this utility, and later on how to use it. We will perform the following steps:

  1. We first need to reference a NuGet package called Microsoft.AspNet.SignalR.Utils, which does not actually add any assembly to the project; instead, it downloads the signalr.exe utility we mentioned earlier.
  2. In order to find the utility, we have to open the packages folder for our solution on disk; from there, we navigate into the folder named after the package name (at the time of writing, it was Microsoft.AspNet.SignalR.Utils.2.0.2) and then we move inside the tools folder, where eventually we find it. Let's annotate the full path of this folder and move on.
  3. Let's now open a console window and set our current directory to the bin folder, where the application assembly can be found, inside the project's directory, and from there let's launch the following command:
    [path to signalr utility]signalr ghp

    This command scans the current folder looking for all the assemblies containing hubs. It processes them, accessing their internals to generate the JavaScript dynamic proxies code, and eventually saves them in a static file conventionally called server.js and positioned in the current folder.

  4. The last step is pretty simple: we take the server.js file and copy it into the scripts folder of our application, maybe renaming it with a more meaningful name. In this case, we'll name it EchoHub.js. At this point, the only thing to do is to change the dynamic endpoint reference in index.html from /signalr/hubs to Scripts/EchoHub.js.

We are done. We can retest the application and verify that we still get the message on the browser console. We are avoiding a dynamic step and we can more easily work on caching the static file the way we think it's more appropriate. The online documentation of this utility can be found at http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-JavaScript-client.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset