[MUSIC]
>> I think the first thing we're going to do,
because it's going to take
about a minute or two is to create a SignalR Service.
Let's do that. I'm in the Azure Portal.
It's fairly easy to do.
I search for SignalR and then I say I want a new thing.
I'm just going to go and create
a new resource group called Webwednesday.
I'm going to go ahead and call it Webwednesday.
>> Very creative in the names.
I appreciate that.
>> I try my best.
Actually. Yeah, like when I code,
well, now, as a PM, I code less.
Naming is the thing I hate the most.
Yeah, I always ask someone else for naming.
I'm going to pick a location nice and close to
me and then I'm going to pick the free tier.
Then down here, you hopefully this is big enough.
I'm trying to pick [inaudible].
>> There you go.
>> There's the default and classic.
I don't need to explain to you
what they are because we're not using them today.
We're going to use a serverless one.
That's the one we can use with Azure Functions.
>> Okay.
>> Then once we go ahead and create it after the button lights up.
Okay. So it's going to go off and get created.
I think in probably a minute or two, we should have one.
While that's happening, let's take a look
at how we can work with it from Azure Functions.
>> Okay. Let's build an app.
>> All right. So I'm going to assume
a little bit of knowledge of Azure functions.
Even if not, I'll try to walk through a little bit of it.
In Azure Functions, the first thing that you need to
do is create what's called
an app and then within
an app you can have more than one functions.
These functions are serverless and I'm going
to be running these locally on the machine right now.
Then some of the other demos that I'll
show are actually going to be running in the Cloud.
>> Okay.
>> First thing, what I'm going to do is
I'm going to say "Create New Projects".
This is using the Azure Functions extension in VS Code.
I'm going to choose this folder that I already created.
I will use JavaScript. Let's see. What should I do?
I need to switch to a different
set of template so I can see everything and I'm
going to use this thing called the "SignalR
negotiate HTTP trigger".
It's a really long name.
Funny enough, I think I actually,
I added this item to this menu and I named that.
See, I shouldn't be trusted with a name or anything.
I'll quickly talk about what the "negotiate" thing does.
You can ignore it when you first get started with SignalR but for,
basically, the browser or
the client to figure out where your SignalR Service is.
It needs the first colon endpoint to figure that out.
That's what the "negotiate" endpoint does.
It's actually part of the SignalR protocol.
The first thing that it does is actually going to make
an HTTP post to an endpoint and by convention,
it needs to be named "negotiate" with documentation and all that.
But then we don't have to do a heck of a lot in
an Azure Function app for this to work.
You can see that using a template,
we already created an HTTP function.
This function will just become an HTTP endpoint in the Cloud.
Because the route is "negotiate",
it's going to be at slash,
whatever HTTP domain name I get,
for my function app /api, /negotiate,
and SignalR Service was just know how to talk to it.
I'll show you that piece of the code in a bit.
Then down here,
we're basically getting access
to this thing called Connection Info and
what this thing does is that it gives you this payload
that you need to return back to
the clients so that it knows what to do with it.
Again, you don't have to worry too much
about how this works because
most of it is done for you by the templates.
But you do need one of these things.
Typically in here, if you need to assign a connection to a group,
or you need to associate a connection to a user so you
can send messages that are only going to be received by a user.
You might need to do a little bit more stuff
in the "negotiate" function.
But typically, if you just want to
broadcast to you everything that's connected,
you don't really have to do anything here.
You just take everything as is and that's that.
I'll run the whole thing in a bit later
because the other thing that I want to show you now
is with the "negotiate" function.
What that allows the browser or
any client to do is to connect to SignalR Service.
The next thing, actually the real thing that your app wants to
do is actually when something happens,
whether it's because you receive
an HTTP request into
your function app or
your function app could be listening for cue messages,
for example, and then every time you get a cue message,
you want to broadcast that out over your WebSocket,
or it could be a change over Cosmos DB or change in Blob Storage.
Basically any trigger that you can set up in Azure Functions.
You can basically turn around and when one of those events happen,
turn around and send a message
to all your connected clients over SignalR.
I've seen stuff like for instance moving stuff around on a map.
Imagine you get an event every time an airplane moves in the sky.
You can actually take that and broadcast that
out to browsers and then you
can actually paint that plane moving on a map. Things like that.
It's pretty flexible.
But for our purposes here,
because we are building a chat app,
I will just create an HTTP endpoint.
How do I do that? Say "Create Function"
and then I just want a HTTP function.
I'm going to call it messages and "Anonymous" is fine.
We don't need security for a demo.
Let's see what should I do? This is just a plain HTTP trigger.
It's going to become an endpoint as
/api /messages and the idea
is that every time we want to send a message,
we can post to this endpoint.
In the body of the message will be the message itself, I guess.
>> People then aren't going to call the "negotiate" directly,
they're going to do everything then through this Azure function.
>> Yeah, so this is the thing that actually does most of the work,
which is relaying a message from one client to everybody else.
>> It'll make maybe a little bit more sense once
we fire it up and then see it run.
>> But what we need to do now is we
need to use what's called an output binding for this.
I'm going to say "Add a Binding" and I want an
"output binding,'' and I want a "SignalR" binding.
Then the naming thing again.
I'll call it messages or new message, what about that.
I think that I'm going to say
"default" here, but I'll tell you why.
SignalR has a concept of hubs,
so you can actually divide
a single SignalR Service into multiple hubs.
You can try and think of them as namespaces.
If your app happens to support
both a real-time chat kind of a thing,
but another part of your app might
support like a little near real-time notification that
little changing the number of
messages that appear in
the corner of your screen or whatever it is.
You can actually have two different hubs,
we call it, to take care of each of those types of messages.
You don't have to worry about using a single hub and figuring out
this message is actually a chat message,
this one is actually a notification,
you don't have to worry about any of that,
you can divide it up into multiple name spaces.
I'm going to call this one a
default and I'll tell you why in a sec.
Then I need to just give it a setting name and I'm going
to call it AzureSignalRConnectionString.
>> That actually is going to be on the server or in Azure,
I shouldn't technically say on the server because it's serverless.
But that's where it's going to sit there and it's going to store
then the location of that SignalR Service, correct?
>> It's actually going to be a connection string.
It's going to include both the location
of it as well as a "get" key.
>> Okay.
>> Then the app setting value.
I'm going to skip that for
now because I need to figure out what that
is and I'll probably want to do this
off screen because I don't want to show you what that is.
Yes, that's done there.
Also another long name.
Again, I came up with that name.
Basically anytime you see a long name,
I probably had something to do with it
because I couldn't figure how to make it shorter.
>> I'm okay with long names.
I mean, if it's something that's going
to be automatically filled, or especially,
if it's something that there's some form
of an Autocomplete or IntelliSense.
Long names are okay.
I would much prefer a longer name that describes what it is,
than a short name where I'm having to figure out
what in the world it's supposed to do.
>> Okay, that's good.
I named this ''binding new message.''
In here now, I can pretty much get rid of all of this.
The first thing that I want to do is get
access to the body of the request.
I'm going to say "const" just message
equals requests.body I think.
But that would give me basically the body
itself and I actually don't really want to do anything with it.
You can do some validation in here if you want.
You probably should because
anyone can send anything to this thing.
But again, demo, no security.
I'm just going to relay this back to all the connected clients.
In order to do that,
I would have to talk with a context which gives me
some bindings and then for these for newMessage binding,
because that's the name I gave the SignalR output binding.
I'm going to assign it to an object,
and I can actually assign it to an array if I want to send
a pile messages out all at once,
I can actually use
an array of these objects, but I'm only going to send one.
I'm just going to just have an object.
This object takes two things.
Again this is all in
documentation so you don't have to worry
about memorizing it like I have here.
The first argument I
guess that it needs is something called a "target".
That's just really a name of an event.
I'm actually just going to just call it newMessage as well.
Plus this is an event's name,
so I'm not going to worry about too much why or what that is.
Then "arguments" and remember
the arguments is an array
and then I'm just going to pass the message.
It's only going to have one argument, but we can have more.
>> Okay.
>> That's it. That's really all the code
that we need to send that message.
>> Really making the case for using
TypeScript here because then I can create
the interface for what newMessage is going to
be and then of course, know what my wreck
is because I can add in the type end in all of that.
If you haven't already started using TypeScript,
you should definitely use TypeScript.
>> Yeah. I'm okay with TypeScript.
I think we had this conversation last time about how I have,
I wouldn't say a love-hate relationship,
but I can go both ways.
I like the simplicity of JavaScript as well.
I'm going to create a very simple HTML page here as we're chatting
to show you how to use an HTML page to connect to SignalR Service.
I'm going to do a couple of things before that.
In my local.settings.json, this is where
we configure that Azure SignalR connection string.
You can see that I pasted in
the connection string. You can't see the key.