Now, it's time to move our attention to the client side of SignalR. We've already written the client-side code in the previous chapters and briefly described the steps we needed to build fully working recipes; however, we never went into the details. Nevertheless, the client portion of any SignalR application is as necessary and important as the server counterpart. Here, we'll explore how a SignalR client really works and concentrate on the specific characteristics of the JavaScript client library in the context of its Hubs API.

The level of abstraction used by the Hubs API lets us reason in terms of the business methods defined on our server-side Hub-derived type. As already explained earlier, we can add as many methods on a Hub as we need, and define with these an interface made up of members with names and arguments which fit our business requirements.

The JavaScript client can access this interface in two different modes as follows:

The latter exposes a much easier to use and streamlined approach, and in our path from simple concepts to more advanced features, we decided to go with this one first, while the second will be the topic of a future chapter.

The Hubs API also exposes the underlying connection and what's necessary to handle it from a client-side perspective. In this chapter, we'll start talking about this.

The key enabler here is the dynamic endpoint (usually /signalr/hubs), which we already saw in the previous recipes where we used the JavaScript client library. It is able to generate a client-side proxy on the fly and contains all the methods that are declared on the available server-side Hubs. This proxy greatly simplifies the way we call the server methods, and it makes SignalR look magical. However, the generated content is nothing more than a smart JavaScript script that you can easily open in a browser's window for further investigation.

When using proxies, SignalR also allows us to augment them with a set of functions that we want the server Hub to be able to call back in order to push information to the connected clients. Each proxy exposes a member called client for this purpose.

The last point that we want to highlight again is the highly asynchronous architecture of this client and of SignalR in general. Asynchronism brings forth a lot of advantages in terms of performance and scalability but also some challenges. We'll see how you can set up and combine your calls when you need to implement specific sequential workflows in the context of an asynchronous API.

For the following recipes, we will always start with ASP.NET Empty Web Application projects and use simple HTML pages for the client portions. As usual, if you want more information on these steps, you can refer to the Appendix A, Creating Web Projects, at the end of the book. The same strategy will be applied when you create recurring assets such as a Startup class or a Hub. They will be briefly mentioned in this chapter and you could go back to Chapter 1, Understanding the Basics, to have some more information about the steps required in Visual Studio to get there.