SignalR and the Real-Time Web

[Microsoft ASP.net] [www.asp.net] Hi, I'm Scott Hanselman. I work at Microsoft in ASP.net, Azure, and Web Tools. And I want to talk about SignalR and the real-time web. And what is the real-time web? What does that mean in the context of ASP.net? Well, there's a number of ways to make websites in ASP.net, and you can mix and match them as you choose. So I want to make a website. Basic HTML. I could use web forms, web pages, or MVC. I want to return JSON and use a service. I could use ASP.net Web API. But in the real-time web, I would use a thing called SignalR. So first, what does that mean? What is real time? Well, remember the first time that you hit a site like Expedia. You had the sense that there was a bidirectional communication link happening between client and server, and they were doing all these calculations, and they would notify you as soon as they found your flight. But in fact, this was a lie. There's just an animated GIF there. And the site is doing a meta refresh tag, and it's simply going, do you have my flights, do you have my flights, do you have my flights? Sometimes they'll use JavaScript. Sometimes they'll use metatags. But the point is, this is polling to make you feel like it is the real-time web. In fact, the browser is just going HTTP Get, over and over and over, and asking the server for the data. It's sloppy, it's a waste of bandwidth, and it's generally not a great way to get a real-time experience and to send notifications and events from server to client. In fact, the best way to do something like this would be to use something like web sockets, and that means that the browser is going to ask the server, do you do real time? Do you support this new model? The server replies, yes it does. So then the client and the browser then switch over to a web sockets connection, and they get to then party on that bidirectional connection. That's great. And then SignalR is the thing that we have on ASP.net that makes that happen. It in fact abstracts all these transports. There's more than just web sockets. You want to have fallback. So SignalR enables you to use not just web sockets, but other technologies. It also lets you think about things in terms of events. It manages all the connections for you. And you can go and broadcast notifications and information to all connected clients or just specific ones. You're getting a real persistent connection over HTTP from client to server. It's bidirectional. And it makes it really easy to build great multi-user and real-time web apps. And all the transport stuff is hidden from you. If your server and your client support web sockets, you'll be great. If they don't, it will find a way to do it. In fact, it falls back. It tries web sockets, and if it's not available, it'll fall back all the way down to a thing called long polling. It's not polling, but it's not web sockets. But the point is that the developer and the user will have a great experience, regardless. SignalR will automatically pick the right thing and make it happen. And that will give you a server-to-client push. You will literally be able to call methods on the client from the server to notify people about things that are going on. Scales out, it's built on async, and it works on thousands and thousands of connections. And it's also worth pointing out that it's open source and available on GitHub. So let's see what that looks like. So here's a little SignalR app, and we'll do this in the context of flights. So I've got Internet Explorer here, and someone is browsing flights, and they're looking at the prices. And I know that you've had that situation, where you wanted to make a purchase, and then, in the time that it took you to add your item into your shopping cart and then check out, the price changed. So what this is going to do is notify the user that that price has changed. In the past, that wouldn't be possible. Literally, you would go and check the price as you moved from page to page. Now I'm going to open up a different browser to simulate being on a different computer. We'll pretend that this browser on the right is some administrator somewhere who's then going to change the price from London to New York. And we'll say that's now $850, and we'll say, Sorry! And then I'll hit Save. And you'll notice that without refreshing the browser on the left, the user is immediately notified of that change. Here in Price Admin, we went and updated the price but then also called our SignalR hub to notify anyone who is connected and listening about that flight, its price change, in the update method. So a call from C# in .Net on the server was then made over the persistent connection, using SignalR, to this browser. And this will work anywhere. This works on mobile. It works on any browser. Whether it be one that supports web sockets or one that does not. This works in the context of an ASP.net application that could be built on top of web forms or web pages or MVC. It doesn't matter. Remember that when you're talking about ASP.net, it's one ASP.net. All of these pieces can be used together. So if you're already a web forms programmer, you can still use SignalR. You can have SignalR working in tandem with these other technologies. It's a really great way to add a sense of connection and build bidirectional communication between your client and your server. I hope you check it out. We've got lots of resources here on the ASP.net site. ASP.net/signalr. You can use this on your local servers. You can also use this in the cloud, in Azure. Again, it's all open source, and it's up on GitHub, so I hope you check it out. Thanks for spending time with me. [Microsoft ASP.net] [www.asp.net]