 Well, welcome back to Azure FunBytes. My name is Jay Gordon. Got a little rough start there, but hey, things happen when you do it live. Welcome back. Hope everybody is doing great. Once again, we've got a great show for you today. My name is Jay Gordon. I am your host here on Azure FunBytes where we talk about the people, the products, and all the things that come together to make up an amazing Azure experience. This week, we're going to be talking about what I just tried to show you a second ago, and unfortunately, I made a mistake. I'm going to fix that right now. We are going to be talking about SignalR service, and what exactly it does, how you can build real-time applications with it, and hopefully add this into your suite of software that you use. Let's try taking that a look at that again. What is the best way to easily add real-time web functionality to an application these days? You know, for things like chat, gaming, dashboards, device-to-provice communication, or a myriad of other instances that are made infinitely better with real-time communication. We think it's a little bit of genius called Azure SignalR service for Microsoft. Azure SignalR service is specifically designed for those creating applications that need to pull servers multiple times a second for each connection, web, or mobile, who prefer to spend their time working on their core business rather than managing backend infrastructure. And the best part? It's fully managed. No more developing plans for outages, scalability, load balancing, security, or even staffing to address all this stuff. All you have to do is provision it and turn it on. Oh, and because SignalR service is developed for Azure, it works seamlessly with its other platform capabilities like Azure Functions, for example, locally or around the world. Want to see for yourself? Head on over to azure.com slash SignalR and try it, free. You'll be up and running with just a few clicks with Azure. Hey, I got it right that time. Sorry about the first roll around, unfortunately. Sometimes when you do it and you do it live, weird things happen. So, hey, welcome back again. Like I said, what we've got today is a great show on that very subject SignalR and to help me do this, to help me get this right, I have Chris Norring. Hey, Chris, how are you today? Hi there, Jay. I'm good. How are things? Great, great. Thanks a lot. So you're a senior cloud advocate, correct? Yeah, that's correct. I'm a senior cloud advocate on the academic team. Awesome. And so that means you're working with people from places like universities, schools, to make sure that they're able to take on these different types of subjects and bring them into the fold. So as they continue and they start their careers, they've got some sort of background, am I right? Yeah, you're correct, Jay. So what's interesting about this crowd of folks, right, is that they're very much in the learning spirit, right? So we try to catch them when they are at their most passionate, right? So they've just learned how to program, they wanna do more and more and whatever service that we can showcase in front of them that's gonna make their life easier and give them real job skills is what we wanna teach. And I believe that Azure SignalR is one such service. Wonderful, wonderful. So one of the things that we'll be talking about is how we can build real-time applications using Azure SignalR. We'll look at implementation of the service that Microsoft Azure provides. And so I think we've got a really jam-packed kind of hour that we'll get into. And I just wanted to remind everybody a few things before we get started, if that's all right, Chris. We'll do it real, real quick and then I wanna ask you a question about yourself. Reminder that if you're here with us today on LearnTV, you can go ahead and find all the notes for today's show. They're up there on the left, or I say the right rail. If you have any questions, you could put them in the chat on aka.ms slash LearnTV. Or you can use your native chat if you're using Twitch or YouTube, all fine. The other thing I wanted to remind everybody about, which I think is really great is Azure open source day and open source. I know Chris, that's near and dear to your heart. We've got a great event coming up that you can take part in if you wanna register now. It's Tuesday, February 15th, 2022. You can go to aka.ms slash OSS day AFB to get more information. So I think that kind of goes through my little run through in the beginning, Chris. So I wanted to ask you a question before we get into the subject because I always like to do some context setting about my guests. And the question is, how'd you get here today? Not physically, but here at Microsoft. How'd you end up in the role you're in and doing the things you're doing? Yeah, Jay, that's a really good question. So I started my career some 15 years ago, plus now I think I started developing applications using .NET web form for the technology. I mean, I'm from Sweden, right? So I spent most of my professional career in Sweden. So some five years ago, I decided to move over to UK. So now I'm based in London. Now, throughout that journey, I had a chance to try out various tech stacks. So I've been trying .NET, Python, and as of late, I've been a lot on JavaScript, but I have definitely not let go of .NET. So I'm definitely doing that as well. And I would say it's as part of being a .NET developer that I first come to hear of SignalR. So yeah, I've taken a geographical journey as well as a technical one to be here today. Very, very cool. And so we'll be learning a little bit about SignalR today and how that implementation works. And I wanted you all to know that there are some great resources, educational resources I know Chris has worked on with Microsoft Learn. So if you want to take a look at, there's this introduction to ASP.NET core SignalR. You can go ahead and take a look at that URL. And then there's also another great, a great module that you can take a look at, enable automatic updates in a web application using Azure Function SignalR service. So all that is in the show notes if you'd like to go ahead and give that a shot. But wait till we're done here, because we got a lot to talk about in just a short amount of time to do it. So Chris, I want to get into today's subject, which is SignalR and Azure SignalR service and how it all kind of fits together. And so the main goal here is building real-time applications, if I'm right. And so why do I need them? And are there some good use cases that you can mention? Yeah, so I think that's a very interesting question, right? Because I think most of us, when we think about apps today, we might have an app, it might have a database, it might have a service layer and some kind of front. And we are used to just, when we start the application, it loads some data and we might input some data and then we press a submit button at some point and that data ends up in the databases. So how do we move from such an app to real-time application? Well, think about it this way. Think about it as data that you want to know about when it happens, rather than you having to hold for it with a polling interval of 30 seconds or five minutes, it's actually telling you when it's starting. So in a sense, imagine NASDAQ, for example, do you want to know about the stock markets? You want to know when that stock is actually dropping or it's going up because you either want to sell or you want to buy or let's say you have a game. You want to know when your favorite player is joining World of Warcraft, for example, or you might have a chat application and you want to chat with people so you definitely want to be told they are here, they are ready for you to speak to them. So there are definitely scenarios out there where real-time capabilities makes a lot of sense and you might want to shy away from a low-grade solution as polling because polling isn't really nice because it's not really real-time. It's just you saying at a regular interval, I want to do this call again for the database and there may or there may not be some new data there for you to have. So I want to build, say, a ride-share application because I am insane and I want to compete with these big people that are doing ride-sharing. And one of the things I know that we'll probably need to do is to get points on a map sent back and forth and updated in our application. And I'd imagine that's a great use case for what we consider real-time applications. Am I right? Yeah, for sure. So imagine you have ride-sharing, right? And as you pointed out, you have a map. You definitely want to know what that driver is. You can look at that map and you see that driver approaching and maybe you even want to hear from the driver and say, hey, Jay, are you there? Can I actually pick you up? Now, at that point, you can define it so that in SignalR, certain messages are being sent as there is some kind of data added to a database, right? So let's say that those locations on the map is added to a database. You add a trigger on top of that and you want that database trigger to say every time a new insertion of a X and Y location is being added to that database that is sent as a SignalR message. By having a SignalR connection, you don't actually have to pull for that. You're just sitting there and waiting for that data to attack you in a sense, right? So you're sitting there in your application and boom, to come data and you see that little plot on the map just moving around. So that's how ride-sharing would work, right? And thanks to Azure SignalR, you don't have to worry about scalability. You don't have to worry about performance because that's our job. Absolutely. And so one of the great things that Azure does is we've got so many ways to actually implement services that will replace what are normally traditional server models where you would have to create a virtual machine and then work with that or set up a server. And so this is a page from that doc that I just showed and there's some great use cases that are all up here, high-frequency data updates, like you mentioned gaming, voting, dashboards and monitoring. So if we've got a number of different services and we wanna create our own dashboard, really great way of using it, chat, especially if you wanna do some live chat agent bots or something like that, locational map like we just mentioned, real-time targeted ads, collaborative apps, push notifications, real-time broadcasting, IoT and matter of fact, real-time broadcasting. Here's a great example of what we're using right this moment, having a real-time application that we're getting messages back and forth, IoT and automation. So these are all relatively understandable use cases. And so I have another question for you, Chris. And then I'm gonna give you some space to start showing me a little bit of what you might have brought to the show today is can you describe the architecture and what major components are involved in implementing Azure SignalR from my app? Yeah, for sure. So I do have a little slide deck. So we're gonna shift into there. I am sure, right? Great. So I just wanted to show you some components that are involved. So depending on- It's a little small. I'm sorry for interrupting you, Chris. It's a little small. You might wanna bring it into, yeah, perfect. Yeah, that's good. That's good. Awesome. Much better. Yeah, so one thing we need to keep in mind is that we need some kind of Azure instance provision, right? So we need to do the work. We need to go into the portal or we need to use Azure CLI and we need to create an instance of Azure SignalR service. Now that service is our connection point and it will handle all our connections, all our messages and keep track of everything, right? And so once we have that provision, what's important to know is that we have a client. So we have a client being a player. One of the first things the client do is to talk to that SignalR service in the cloud. And once it does that, for the first time it does a handshake. So it's talking to the SignalR service and say, hey, I'm Chris, I want you to know about me. So at that point, the Azure SignalR service sends back a connection object. Once you have that connection object, you essentially have a persistent connection, right? It knows who you are, you know where to go. And when you have that connection, that means that any kind of messages that you're gonna send from the non, you know exactly where to go and any kind of messages meant for you, it knows where to send them. So in a sense, depending on what architecture that you select, because there's more than one, this is the meat of the architecture. Now, Jay, you had an excellent documentation page there that kind of described three different architectures. And depending on if you go with .NET, you're gonna use an architecture involving hubs. So that one is a little bit different. But I thought I'd show you the one that is serverless because that's your second choice. Now, the idea of having a serverless connection is that you are building an Azure Function app and having at least two endpoints. One endpoints for that handshake and at least one endpoint I will handle in a type of message. So if you were to send a message to all the other clients that were to listen, you would need an endpoint for that. You definitely need a negotiation endpoint as well. So the idea is that you, from your client, talk to the Azure Function app that in itself talks to Azure SignalR instance in the cloud. So yeah, so from the way you stand as a client, you are only talking to a normal backend but it's being reactive in the sense that it is using Azure SignalR. So if you know how to build a client, if you know how to communicate towards a Azure Function backend, there's not a lot that you need to do at this point. So this schema here is showing how things can work. So the idea here is, if you see this picture, is you start off by connecting to your Azure Function app. You get that connection instance back in third step. And if you look at here on the right side, we can see that what's happening is that the middle client here is sending and the two other clients on the left side and the right side is receiving the messages back based on the fact that you go to the Azure Function app, it goes to the cloud and the cloud is sending what's called an outbound message that will be sent to the other clients. Yeah, so that's a little bit about the architecture. But yeah, I wanted to reiterate one more time about the documentation page you showed because you showed supported runtimes. And I think it's important to say that Azure SignalR can really be used by anyone, right? So if you're on ASP. Yeah, so you are on ASP.net. You definitely have a method and architecture to use. It's a bit different than the one I just described. But if you are on C sharp, if you're on JavaScript and Node.js, if you're on Java, if you're on Python, you would be using an Azure Function instead. But you also have the third option, which is a REST API. So if you're using Rust or Go and it supports HTTP, you can actually implement SignalR using that. So you have a lot of options of how to implement SignalR. So which MO that you choose forward is really up to you, right? Absolutely. And so obviously you're going to be using the service within Azure. It's like all other services with Azure. There's money associated with it at some point. And so what pricing tiers exist and when am I being billed for this service? Yeah, that's an excellent question, right? Because we all hear that something is free to begin with and then it's not so free. And we kind of want to know the trigger points for that. So let's talk a little bit about billing, right? Because when you create that instance, you do so selecting a pricing tier. And first off, when you're starting off, you might select a free one because you want to see if it works, right? But there's also the standard tier. And if we have these two alternatives here side by side, we see that with the free tier, it has 20 connections to start with. You can send as much as 20,000 messages per day, which is quite a lot if you're just testing it out. If you are on the standard one, you see that you are easily in the millions. Now, as for your second question there, which is an excellent one, when am I being billed? Well, first off, you got a monthly cost of $29 a month. That might vary a little bit per region. So I definitely encourage you to go into this pricing calculator here so you can see exactly how much it costs for you and in your currency. But as for being billed, one thing you need to keep in mind is something called outbound messages. And the outbound concept simply means when I go from the server and I go towards my client, that is counted as outbound. When I communicate from client to Azure, it's actually inbound. So if we understand that the outbound part is when we're being billed, there's another factor that also affects your billing and that's the size of the message. So if your message is four kilobyte big, for example, it's counted as two messages because the limit per message is two kilobytes. So imagine that here, that you're sending this four kilobyte message. It's being sliced up in two different messages per client, but they will arrive sequentially to each client. So two messages here, two messages there, two here and two here. So you sending that first message to three clients plus a server is gonna be a count of eight messages. So if we just head back here to our free tier, we can see that if I were to send that message in that situation, I can see that I need to deduct eight messages from those 20,000. So if I wanna know the rate at which I'm burning my message account, it's kind of good to know how it calculates. So if I'm being very, very wordy, I mean, four kilobytes in text, that's a lot of text, right? But if you were to- It sure is, yeah, yeah. Yeah, I mean, if I were to send across something else than text like images, I mean, four kilobytes is nothing. So it's kind of good to keep in mind that I just wanna connect again to what you said about that ride sharing app. You're more likely to send the X, Y and Z coordinates, right? You're not likely to send a picture of the driver every time. So using fCNLR in such a context, I mean, four kilobytes, yes, you're gonna be within those two kilobytes and you're gonna be within it counting as one message. But I'm thinking it's kind of good to know the outbound concept versus the inbound and the message size. And also that you have like a basic cost per month that is what you will be paying for. But if you need more than one million messages per day, then you're probably a very, very big company. And you see that if you wanna scale that, if you want more units, you can definitely do so. But you see for every unit, there's a thousand connections. So imagine that you and me, Jay, we are talking to 998 other peers. And if I'm in a ride sharing app like Uber or Lyft or whatever, right? You can imagine that a thousand cars, well, yeah, sure, they have more than a thousand cars. But if I'm just starting out in my basement with maybe 10 cars or 20 cars, I can definitely use Azure SignalR. I can most likely get away with this $29 to start out and I'm not gonna be robbed, right? I don't need to go to a venture capitalist and ask them for millions of dollars. So hopefully you feel, yeah, go ahead. I have this image and I wanted you to take a look at it. It's from one of the documents, which is actually getting started with the real-time apps. And there's this interesting kind of architecture diagram. And I was wondering if maybe if you can take a second, kind of go through the steps that we have here because it looks like our application that what's presenting is up at the front. So where would we find SignalR in this particular kind of architecture diagram? Yeah, so this is a really great picture because it's showing us two different scenarios. One using web sockets and the other one, AJAX Long Poland, right? And polling is the way that we use to make sure that stuff is perceived as real-time before we had sockets. So what's great about SignalR is that it's an SDK on top of that, right? You should be agnostic to whether it's actually able to use sockets and if it can't use sockets, it will default back to polling. So the great part about SignalR is that it encapsulates whatever real-time approach that you want to use and gracefully degrades to whatever features that you have on your system. The important part for you as a developer is that you shouldn't care. So looking at the left side, that's your best case scenario, right? That's your device supporting web sockets. And yeah, you can definitely say that, yes, it's transporting messages. It's using a persistent connection API through the SDK. And yeah, you have your web browser application and looking at the right side, we see that you are getting pretty much the same thing, but it's using polling, right? So yeah. And if I'm right, there's three different types of ways of doing this with SignalR. I know that it's like long polling web sockets and there's one more if I'm right, isn't there? Yeah, I believe the, let's see here, I don't want to mix things up, but I do believe the hub approach might be a third one because I know .NET intrinsically uses a different version because .NET was the first runtime to kind of adopt SignalR and then it kind of moved into being more agnostic, usable by JavaScript and Python and all those other great languages. So we're going to be talking a little bit about the scaling aspect and I thought this was a really good document with an image to show as well. The different types of way of actually hosting SignalR and so obviously you can do self-hosted, which also means that you're gonna actually maintain the underlying system, the operating system, the required software to actually run SignalR or you can use the Azure SignalR service, which as you described, it's a subscription-based service, it's run as a platform that you can implement as part of your application architecture. And so one of the other questions I have for you before obviously you can show us is how does it scale and can you describe how I would scale it and what I need to know? So depending on approach you're using here is a different kind of scaling, but I think it's a great picture that you showed. So the app service, we talk about something called point of scale, right? So the app service will be the point of scale. So if you need X number of instances of app services that is running, that's how we would scale. Now, normally that's built into a pass or platform as a service, meaning that you don't really need to care about that point, right? I mean, you can have an app service run across regions and have it scale as much as you want. The only thing I guess you need to keep in mind there is the cost. I believe that, I can't remember right now how app service is being built, but I think there are different things like how much data you're using probably. I don't think you're paying for the actual scaling, but you're rather paying for the messages being sent across, right? I do believe that there's some instance cost. Yeah, there's a couple of different SKUs that are like a basic standard for production, premium enhanced, isolated, things like that. There's a few different levels that get built, I believe by the hour, so pay as you go for the amount of time that the actual application is online. And so it differs obviously from serverless and a function because those are always being maintained. They're always online, they're always active, whereas for their functions, which I know it's funny about, normally they're run and accessed when it's some sort of triggering process occurs. So I think we've got a little bit of understanding about what SignalR is, how it is, why it is. And I'm curious if you can maybe show me a little bit of how we can do the actual implementation. Yeah, 100%. So let me just go back and share some more slides because I believe I had a video. It's always good to have a backup. Let's see where we are. Yeah, so here, what we're looking at here is a backend project. I'm not sure you're able to see, but I can explain what you're looking at. So here we have generated an Azure functions application. Now, as we all know, we can generate that for whatever runtime we want, which could be Python, could be for .NET C sharp, could be Node.js, even PowerShell. Now, what's important to look at here is that we have two different endpoints and the way that an endpoint is defined in the Azure Function app is that we usually have a director with a certain name. We have a function JSON and we have some kind of code file. Now, this is the approach used by a bleep Python and JavaScript. I think C sharp is doing this a bit differently by having one file with a lot of functions in it. But regardless of which, the negotiate one is interesting because that's the thing that you at least must have. Now, looking here, we see that we have zoomed in on index.js, which is the code file. What we see here is that if this one is being triggered, we see that what it does is that it assigns something towards a response object and its body. And what it assigns is the connection information. Now, the negotiate endpoint is being called when a client connects towards your backend. Now, we'll show this by just running this video. So what we're looking at here is that we first start off the backend. So we have that up and running. That's great. So we have a backend. And what happened here, you might not have seen it, was that the first thing that happened is that I started a browser and when I start my client, the way that the client is written is that I have a piece of JavaScript code that tries to connect to this, the first thing it does. So it goes to wherever the signal or endpoint is living. And the first thing that happens is that it hits a break point. Now, once it hits that break point, what I want to convey back to the client is that here you have a connection object. When you have this connection object, you and me, we know each other. We know how to talk to each other. I know how to send you messages. You know how to push messages to me. So if we go past that point, we see that we can let go of that break point and we can return that back to the client. And once we do that, yeah, let's see if I can fast forward this a little bit. There. We are in a chat, right? So I have opened up a chat. I am Chris and now I'm fully connected because what's happened at this point is that my client that I started up connected to my back end and once it connected to my back end, everyone's happy because the client has gotten this connection object back, right? Now, I want to start a new client. I want to talk to you, Jay, right? So I have a second client here that where I point out the back end and I give you the opportunity to input your name and same ML happens again. In this case, you go towards your back end, the same back end, and you also receive this connection information. So you're also connected to the signal or service and we are able to talk to each other. Now, at this point, I'm adding a message and I'm saying hi, Jay. Now, at this point, I'm not reaching the negotiate endpoint anymore, but I'm reaching a different endpoint. I am reaching an endpoint called slash messages. So if we look here, this is a different endpoint as part of our Azure Function app and it does a different thing. Looking at this code here, what's going on is, if you look here from line 10 and down, is that I'm going to end up producing a signal or message and we can see that as part of line 12 here, where we set the target value and we call that new message. Now, the value new message, this is something I choose. I can call this whatever. I can call it as me sending message to Jay or here's your coordinate for your app or here's the stock market information that you want. I choose to call this new message. So this is an agreement that the back end and the front end needs to have with each other. We need to know what message is that we're going to send to each other by the name of the custom event. So now I have started the contract from the back end. I call this new message and I give it the value and the value is part of the arguments here on line 13. So that's great. You are answering back to me and saying hi back, Chris. So at this point, at this point, hey, Chris, the breakpoint is being hit, right? And if we look at the breakpoint here, we see that hi back Chris is part of the text property and we see that the sender is Jay. Now, what I want to do at this point is to go to line 10, where the message is actually being sent via Azure SignalR and that thing is going to hit and I'm going to receive that on my client then. So what I want to do is to let go of the breakpoint but I want to investigate in JavaScript how come this works? Well, it works because when I start my connection object, one of the first things I do with my connection object here if you look at line 127 is that I have initiated a connection object. The first thing it did was to go towards that back end and it returned a connection object. But on line 127, I see how it listens to something called new message and this is where I said that the client and the back end are in agreement what they call this because I know that the back end is going to send something called new message and when that happens, I will know. So when new message happens, it will invoke a function and say, hey, Chris or Jay, depending on who gets the message, here's something that I want you to know about. So new message here is a function. It takes message. This is the message that comes from the back end and this message is being added here on line 147 to something called data, which is an object that I associate with my JavaScript application. Now, in this case, I have a JavaScript application that's a UGS application, but you can definitely use React or Svelte or even regular JavaScript to make this work. So on line 74 here, I'm setting the data property as part of my view application, which means that whenever this data is being set, the data is being updated as part of my UI. And if I look at my UI code, it from line 40 and below, what it does is that it loops through all the messages that I have. So this means, Jay, that when you send me that message, it will affect that data property messages, which means that my UI will be updated because that's how view and any kind of reactive front end framework works. And if we go through this little bit, we can see that when I let this go, I see that the message is appearing. And this is all thanks to how my client application works. It listens to that new message. It says, thank you very much, Jay, for sending that to me. And now I'm going to update the UI. So that's really how the flow would work with me having a client that starts off by connecting. Once I connect, I sit there and listen and I wait for Chris or Jay to talk to each other once they do. My client's going to say, ooh, thank you very much for that new message. I'm going to better update my UI application. So I'm actually going to take you from this demo and I thought I'd take you through all the flows. So we understand, well, Chris, what are all the bits? What do I actually need to do? Can you remind me again? So I'm thinking I just take you through all the steps that I went through to create this application. First thing I did was I went into a portal asher.com or I could have used Azure SignalR. First thing I do is to type signal. That means it's going to show me the services here at the bottom called SignalR. I'm going to select that. Once I select that, I hit this Create button. Once I hit my Create button, I'm getting this form that I'm sure most of you are used to seeing by now. I need to fill in some things. I need to fill in my subscription, what I call this resource, what region I'm in, because it matters how fast these messages are going to show up. And then I need to select the pricing tier, which is either free or standard. I can change that if I want. And I need to set the service mode. Now, if I'm using the serverless version, this is that's something I need to keep in mind. But if I'm using the ASP.NET version, I don't need to do anything here. But let's say then that I provision this instance, I can then go in afterwards in my provisioned resource. I can go into the Settings property and I can set this serverless property, which means it's set up to work with my Azure Function app. Now, once I have my Function app, sorry, once I'm done there, I can go to VS Code or Vision Studio. I can generate my Function app. And then I need to set up this slash negotiate route, which I can do again via VS Code and just generate a new endpoint. What's important here is the bindings. Now, one piece is important. One, I need to reach this via an HTTP trigger. That means that my client will need to reach this via request. If you remember seeing from the browser, one of the things you were asked in that modal is where do I need to go? In my case, I said you're on localhost 7071. So that's great. But this type here that says signal or connection info, this is that decides that what's being sent back once I connect the first time is the connection info for signal R, which enables that the client on the back end is now handshaking. And yeah, once that's done, I need this code. It's not a lot of code. All I need to do is just make sure that the response object's body is being set with the connection info and send that back to the client and they are connected. Now, the other piece of endpoint that I need at least one of is I can have many types of messages. If I have a ride-sharing app, I might have one endpoint for sending chat messages, one for sending XYZ coordinates and so on. But this endpoint is doing messages. So it is being triggered by the HTTP. If I want to talk to UJ, if I want to send a message, I send a request towards a certain endpoint slash messages. And the output here is a response of type signal R, not signal R connection info, but signal R. And this is how signal R knows what kind of message and it knows to tell all the other listening clients. Now, how we handle the incoming message is the return bit here where we say target is of type new message and the arguments is the value that I want to send back. And yeah, one thing that you definitely need, otherwise this won't work at all, is that you need this piece of information in local settings, JSON, when you're doing things locally. And that means that you need the Azure signal R connection string and this is a connection string that you can get from the portal. But as we know, once you deploy a function app, you can synchronize this with your app settings, right? So everything in here could be moved over to your app settings tab that you have on your resource. Yeah, so that's how all the code works and how it works via the demo. We talked about some learn models, I believe, Jay. And you said, yeah, ride sharing apps, great. But you could also have a finance app, right? So I thought I'd show you an example where you can take that finance app that you don't like, you built it circa 2003 maybe. It worked at a time, but now it's 2022. I got that, right? I was about to say 2021. Imagine though that you're still working on that same awesome finance company and you're being tasked and someone tells you, Jay, can you update this app for me? It's working by polling. And you're like, oh, God, I don't want to go in here. I don't want to fix this. But then you hear about Azure signal R and you're thinking, sweet, I better try that, right? So I go in here and I learn all about how to use Azure Function and I set up my function app just as I mentioned. And what I do is also to make sure that I have a database insert trigger on one of my endpoints, which means that if someone who works on the finance department suddenly have access to it and can update that database, I have a function app that reacts when something is being inserted in that database. And once something is being inserted, then it can actually push via signal R to the client. And suddenly you can delete all that code who does that polling behavior. And instead, you've just set up Azure Function by just writing code that probably took you at most an hour, I think. And you probably spent 50 of those minutes looking at docs and you're actually writing code timings is probably somewhere around 10 minutes. So yeah, if you know how to use this, if you've got some awesome docs resources that you showed everyone, Jay, I believe that you can take any kind of legacy app and feel really good about it if you already have that capability. Very cool. All right. So I wanted to go into the portal for a second if you don't mind, Chris, because I've actually created one of those services that you kind of showed us just a moment ago. And if we could just kind of take a quick look, let me make it a little bit larger for our audience. So when we create a signal R service, we get a fully qualified domain name of where it's hosted here locally. And we can see that we've got some tools and SDKs that come along as well as some monitoring. So we've got like two sections of SDKs right here, the control plane for our standard languages that we would want to use, and then the data plane. And I'm not too sure about the data plane because I can understand the control plane. Do you want to talk to me just for a second? About what that data plane is and how it's accessed? Yeah, for sure. So with a client SDK, for example, on the data plane, what that means is that when I'm building stuff in JavaScript, I have an SDK file that I'm pointing to that lives on the CDN, which means that what that SDK will give me is a connection object that I can point towards your backend that you've set up there. And it will also have the ability to send messages also and listen to messages. So connect, send, and listen, which is pretty much the three basic functions that you need on the client side of things. So if you were to click that client SDK, you would actually come to the implementing JavaScript code. Now, as for the other piece in the data plane is the service SDK. Now, if you're using an Azure Function app, this is a capability that you're going to need. So you have a capabilities file as part of your Azure Function app. That enables you to set these various triggers, right? So remember how I said that there was a inbound connection info of type Azure SignalR? That's part of the backend and the data plane or that you wanted it to answer with a SignalR thing when I sent the message. That's the other piece, right? So, yeah, it's three pieces that you need to remember on the client and there are two pieces that will give you those capabilities on the backend. And so I know you mentioned connection strings. I was just going to say the next thing, I know you mentioned connection strings and right here on the left rail, we can actually see that we can go in here, we can create a connection stream for our client endpoint, set up an access key, managed identity, so if we don't want to manage, we can use Azure's AD for our AD application as well. So we have a client ID directory, so I'm guessing that this is a service principle that we're popping in here. And the other thing that I like is that on the left rail, there's quick starts. And so I wanted to maybe step through this a little bit with you if that's okay. Yeah, sure. So the first thing we need to do is use SignalR and the configure services. And I was curious if you could just give me a little background on what this particular code is doing. So this is .NET, right? So what you're inside of is a startup application file. So one of the first things that happens when you start off a .NET application, it is running this file and is looking for configurations that you might have in your environment variables or as part of your secrets. And the part that's important here is two different methods. First, configure services. This is where you tell it to have the capabilities of Azure SignalR. So if you look at configure services, you see that it's doing add SignalR, add Azure SignalR. Those two lines are very important because it gives your app the capabilities. But at this point, you've said this middle where exists, but you haven't actually told it to use it. That's the next step. That's what happens in the configure method. Now, if you scroll a little bit in the configure method, that's at the bottom of the screen, you see that it's doing something very interesting. It's calling use Azure SignalR. This is where you are showing intent. I mean, if you in configure services said, this is a capability I want you to have, in configure, you're saying, I actually want you to use it. And as part of that, I am setting up an endpoint. So you're setting up a hub. This is using the other ways of doing things with as a speed of net. Remember if I said this is the non Azure function version. But what you're doing is to setting up a map hub chat at slash chat. So you're setting up a backend so people know where to go to chat for messages. Now, what we're looking at here is, first off, how to broadcast messages. So this is what you're doing here is to send a message. So you are giving it a name broadcast message. You could be calling that anything. This is just a chosen string of your choice. You could say, Jay is sending a message. The important part is that the first parameter is the name of the message. The other two parts is things that you will need to send the message across, like name and message. Now, echoes are not something that you're being built for, but it's something that makes sure that there's like a keep alive function. So that's not a ton of code, right? It's only showing you the bare minimum of what it needs to set up the hub. And if you remember that we talked about a hosting option where you are doing stuff in app service, this is the code that you would need on your backend. This is the dotnet application that you would need to deploy to leverage app service. Now, with that said, you still need a client that connects, and that's what happens in step three. So what you're doing here is you're first trying to connect to it. So bind connection message. We can see here that our connection is interested in listening to certain messages. That's what happens on connection on. So it's listening to broadcast message, and it's connecting a message callback function. And the other connection on is doing an echo, and it's listening to echoes. And if I remember correctly, echoes are to make sure that things are still there. So you're not sitting there in cyberspace and you're saying, hi, Chris, where did you go? Why are you not here anymore? Answer me, right? So you kind of need that one. If that one suddenly times out and says, I don't want to talk to you no more, you would know from the echo that, hey, sorry, the backend is up and left. So yeah, if you see that connection being created with bar connection equals new hub, what you're doing here is directing it towards where do I actually find my backend? You're telling it that it's at slash chat, and then you're calling build, and that means that you now have a connection object. So now what's happening is when you call connection start, a couple of lines down, is that now you are initiating that connection from the client towards the backend and said, hey, I want to handshake with you. I want to say I exist, right? So when you tell it yet you're exist, just like the Azure Function app architecture, it's going to send you a connection back, a persistent connection that opens up this tunnel between client and backend, and they're going to say, I can send message this way and you can send message this way. So it's completely open. It's not like the usual stateless HTTP thing here. It's a socket connection, right? And should that connection go down, you see that we have this catch function that's going to say, hey, something went wrong in the backend, just disappeared. And send it to the error log, and if you're taking error console messages with your error log, you can go into that, you can determine what cause, maybe there was some sort of transmit failure somewhere along the way. So we got a question in, and I think that it's, we might have just touched on it, but I want to just double check. Phil wants to know how is authentication handled? How do I validate clients? Is it via a function app, of like, anonymous keys, OAuth2? Yeah, so I think that's an excellent question. As we, in function app, we can use Azure AD, but we can also use the, in the function app, right? You can also use an API key, but I would say this, you don't want to run your own way of validating that user should be here, right? So you probably want to use something like Azure AD, or you want to use OAuth to support that. Now, because of the way that the Azure function app architecture is set up, it's set up to work with, for example, Azure static apps. And that's another service that works really well with Azure Signalor. And the idea there is to have a client on the front end, and the backend that would be a function app. When you deploy those two together, right? You get this Azure static app. And as part of that, you can leverage social auth, you can leverage Azure ADs. So you have a lot of authentication options. So I would say, if you go down the route of using Python, C sharp JavaScript, and you don't use the hub approach that you showed right now, you can definitely use the authentication page. That's part of the Azure static apps too, authenticate your users properly. And I believe they have a dedicated doc how to set that up. But part of that is knowing that you have a lot of routes that's already set up to handshake the authentication bits and everything else and decide permissions towards certain endpoints, for example. Gotcha. So we got through the big need of everything. We even took a look at the service within Azure. You showed us some code examples. He explained a little bit of code for us. And we've got a little bit less than eight minutes left. And I was curious if there's anything else you think is worth mentioning before we start wrapping up. I think it's important to mention that there are these three different options. And the fact that if you're a C sharp developer, my guess is that you're going to be a bit confused because you're saying, I know signal are from back in the days. I haven't heard about Azure signal are. I've definitely added real time capabilities some five, 10 years ago when signal are still existed. I think it's good to know that as a C sharpen dot net developer, these two options exist for you. So you can either use a function app with C sharp that works perfectly fine or you use that approach that you showed in the sample docs where you're using the hub. And that works too. But what you need to know is that the hub solution is using a version that you need to deploy your dot net app on an app service. Whereas the other one is an Azure function app to that you are deploying. Both those are viable options. But for everyone else who's not a developer, you don't have the full smorgasbord, right? You have the Python, you got JavaScript. And if you're out of luck and you're using some exotic language like Rust, you definitely have the REST API. So under the hood, under those SDKs, there is a REST API where you can connect, you can send messages, you can send echo signals, you can do a lot of things. So that docs page that shows you those tutorials is a really good one, right? Because it shows you those different approaches. Yeah, and we've got lots and lots... Oh, I'm sorry, go ahead. I just wanted to show everybody there is some great docs here, the SignalR Getting Started page, the introduction to SignalR, and then the Azure SignalR Service documentation, which gives you all the bits and pieces that we kind of took a look at real quick. Yeah, and also, I think it's kind of good to keep in mind how that billing model works, because I don't want to come in here and say, this is great, and then you end up getting this huge bill, right? So there's a billing chapter in there when you can see, but hopefully, by today's talk and discussion, you know more about, oh, outbound messages. I understand when I'm being billed, and I understand that I'm being billed, and it matters the size of the message. So if I suddenly get this huge bill, there's a reason, maybe you're sending millions of messages, and if you are, and you have a chat app, there's definitely some wild true code somewhere, right? So it kind of, yeah, go ahead then. Oh, it's gonna say, and they're going along the way of talking about documentation. There's a GitHub project with a bunch of samples that I think people can take a look at under the ASP net. So some of the things that Chris has done today, you can do it on your own. There's the advanced chat room, chat room, so you can take a look at the Azure signal, or all our samples repo within the ASP net, and start building on your own if you'd like to. Chris, I got a question for you before you kind of finish up. One of our viewers wanted to know if you have a copy of this deck so that they could take a look at it on their own. Yeah, 100%. I can definitely send that across to you, and we can get it out there. One thing I wanted to say to wrap things up is that can we go back to that SDK sample, because I'm thinking that's on GitHub? Oh, yeah, sure. So what's good to know, because one person in our audience there asked about authentication. Now, one of these samples actually have authentication built in. I can't remember if it's the chat room local or chat room. It's one of them. So if you look at the pieces there, it's dealing with authentication using Azure Static Apps, if I remember correctly. So this looks like .NET. That wasn't the one. I think it had JavaScript on the back end. So one of these is a very simple, it doesn't use any authentication, and the other one is. So if you want to have this head start, knowing how to authenticate, that's also .NET, right? Yeah. So here we are. Here's some more .NET. Looks like they're all .NET in here. Yeah. So if you go from the official docs page, I believe it's leading you into here. But so one of the examples, definitely I can provide that link after this, is using authentication. It's using Azure Static Apps. So that's kind of good to know, to understand at what point am I being authenticated? How do I ensure that the right person is talking to the other right person? For example, if you have the right sharing app, you don't want the wrong driver to be talking to you, right? Absolutely. So we're just about at the end, Chris. And I wanted to make sure you had an opportunity. Do you have any other events or things that you're going to be doing or new pieces of work that you're looking forward to sharing for audience so they know? Yeah, that's a fantastic question, Jay. Thanks for that. We have a lot of repos that we have been creating as part of our academic team. We have a lot of four beginners repos. So for example, web development for beginners. We have 24 lessons, machine learning for beginners, and so on. One thing that, so that's what's already exist. Now, what's in the pipe that I'm really excited about is the fact that we are about to create a lot of workshops right now as part of our team. And I'm hoping to share that soon. So that will definitely come as part of a workshop repo. So that's up and coming probably in a month. Let me also provide you with a link to a lot of these .NET workshops because I believe one of them is using SignalR, both the old version and the Azure Static apps once. So they have a good sample and a good starting point. But hopefully everyone today that you feel like, yeah, okay, I kind of get it how it works. I got two clients, I got a backend, that backend is talking to Azure and so on. So hopefully y'all don't feel intimidated by trying to add some real-time capabilities because that can really make a world of difference of how responsive your app seems. Well, I'll be getting those links from Chris. We'll put them in the show notes. It'll be on the dev.tubelog post that comes up shortly after so that you're able to kind of take a look at these code samples, these different ways of implementing these things that the educational team or academic team rather want you to take a look at. So Chris, we're right at the end of it and I just wanted to say to you, thank you so much. I really appreciate you being part of the show today. I learned a little bit more about SignalR. I went through some of the learn module yesterday and kind of just tried to grok as much of it as I could just so I felt like I could ask some smart questions of you. That's really it, Chris. I know it's a little late in the evening for you so I really appreciate you taking some time out of your evening before you settle in for a nice relaxing end of your day. And I just wanted to say thanks so much, Chris. Thank you, Banshee. I'm super happy to be here for the second time to see all your series, how it plays out. So yeah, super happy to be here and I hope everyone who listened in today that you felt like I'm actually being inspired or maybe you even got some questions answered. So great to be here. Thanks a bunch, Jay, and thanks everyone for listening. All right, everybody. Until then, let's give them the big wave. Goodbye. We'll see you next time. We've got another great show coming up next week. Always appreciate all you take and pardon it. We'll see you then.