WEBVTT
00:00:00.000 --> 00:00:01.575
>> On this episode
of the ON.NET Show,
00:00:01.575 --> 00:00:02.425
we're going to learn
how we can build
00:00:02.425 --> 00:00:04.150
real time applications
using SignalR,
00:00:04.150 --> 00:00:05.995
and also the Azure
SignalR service.
00:00:05.995 --> 00:00:09.780
>> Save the date for .NET
Conf 2018, on September 12th,
00:00:09.780 --> 00:00:11.570
through 14th .NET Conf is
00:00:11.570 --> 00:00:13.950
a free three day virtual
developer event,
00:00:13.950 --> 00:00:16.485
co-organized by the .NET
community and Microsoft.
00:00:16.485 --> 00:00:18.240
You'll enjoy a wide selection of
00:00:18.240 --> 00:00:20.730
live sessions that feature
speakers from the community,
00:00:20.730 --> 00:00:22.230
and the .NET product teams.
00:00:22.230 --> 00:00:25.065
Head over to www.dotnetconf.net
00:00:25.065 --> 00:00:27.470
to learn more and save the date.
00:00:38.770 --> 00:00:41.655
>> Welcome to another episode
of the ON.NET Show,
00:00:41.655 --> 00:00:43.240
my name is Russell Philip,
and with me today I
00:00:43.240 --> 00:00:45.205
have Anthony Chu. What's
going on Anthony?
00:00:45.205 --> 00:00:46.685
>> Not bad. Thanks for having me.
00:00:46.685 --> 00:00:48.790
>> So, you are actually
here to talk to us
00:00:48.790 --> 00:00:51.715
about the Azure SignalR service
and SignalR in general,
00:00:51.715 --> 00:00:53.340
but before we do that, why
don't you start off with
00:00:53.340 --> 00:00:54.860
just telling us a little
bit about yourself,
00:00:54.860 --> 00:00:56.365
who are you? What
do you do there?
00:00:56.365 --> 00:00:58.230
>> Sure. So, my name
is Anthony Chu.
00:00:58.230 --> 00:01:00.270
I'm a Cloud Developer
Advocate at Microsoft.
00:01:00.270 --> 00:01:01.800
So, same as Russell,
00:01:01.800 --> 00:01:03.495
and we actually
working the same team,
00:01:03.495 --> 00:01:05.040
with a focus on.NET.
00:01:05.040 --> 00:01:08.270
So, lately I've been
working quite a bit with
00:01:08.270 --> 00:01:10.920
ASP.NET Core SignalR and also
00:01:10.920 --> 00:01:12.930
with the new Azure
SignalR Service.
00:01:12.930 --> 00:01:14.605
That was announced back at build.
00:01:14.605 --> 00:01:17.065
I'm also with Azure functions
00:01:17.065 --> 00:01:18.610
to see how we can actually take
00:01:18.610 --> 00:01:20.305
some of the SignalR goodness
00:01:20.305 --> 00:01:22.625
and integrate it with
Azure functions.
00:01:22.625 --> 00:01:24.915
So, we can have serverless
WebSockets, if you will.
00:01:24.915 --> 00:01:26.520
>> Okay. So, you've
been saying SignalR.
00:01:26.520 --> 00:01:28.260
We've used that word
a couple of times before,
00:01:28.260 --> 00:01:31.490
but what exactly is SignalR?
What can we do with it?
00:01:31.490 --> 00:01:34.470
>> Yeah, so SignalR it's
a library for ASP.NET
00:01:34.470 --> 00:01:37.350
and in this case it's been
00:01:37.350 --> 00:01:40.350
a core that allows us to
00:01:40.350 --> 00:01:41.850
add real time capabilities to
00:01:41.850 --> 00:01:43.870
an ASP.NET Core application.
00:01:43.870 --> 00:01:45.890
So, what I mean by real time is,
00:01:45.890 --> 00:01:48.430
if you imagine some of
the use cases for real time.
00:01:48.430 --> 00:01:50.260
So for instance, if
you have a stock app
00:01:50.260 --> 00:01:52.300
or a stock website
where you go there,
00:01:52.300 --> 00:01:56.890
and the server is pushing real
time stock prices to you,
00:01:56.890 --> 00:01:58.650
and the screen is
updating it real time.
00:01:58.650 --> 00:02:00.190
Or maybe your looking
at some flights and
00:02:00.190 --> 00:02:01.510
you look at the map,
00:02:01.510 --> 00:02:03.585
you see some planes moving
around in real time.
00:02:03.585 --> 00:02:07.065
So, those are some of the
scenarios that SignalR enables.
00:02:07.065 --> 00:02:10.050
>> So, what if I know in the past
00:02:10.050 --> 00:02:11.320
we used to do this thing
00:02:11.320 --> 00:02:12.740
where we just pull
the server, right?
00:02:12.740 --> 00:02:14.540
Like hey, we're ready
for your information.
00:02:14.540 --> 00:02:15.970
We'll just ask for it.
00:02:15.970 --> 00:02:16.090
>> Yeah.
00:02:16.090 --> 00:02:17.380
>> What's the difference
with me doing
00:02:17.380 --> 00:02:18.880
that and using something
00:02:18.880 --> 00:02:22.135
that's like SignalR for
instance that's real time.
00:02:22.135 --> 00:02:27.545
>> Yeah. SignalR by default uses
WebSockets if possible,
00:02:27.545 --> 00:02:29.780
and it's a lot more
efficient to use WebSockets.
00:02:29.780 --> 00:02:33.925
WebSockets is a persistent
and bidirectional connection.
00:02:33.925 --> 00:02:35.815
So, that not only
can the client push
00:02:35.815 --> 00:02:38.200
information obviously send
messages to the server,
00:02:38.200 --> 00:02:39.730
the server can use
the connection to
00:02:39.730 --> 00:02:41.460
send information in real time.
00:02:41.460 --> 00:02:42.955
Basically push information
to the client.
00:02:42.955 --> 00:02:44.620
So, you get stuff
right away instead of
00:02:44.620 --> 00:02:46.660
waiting the five minute
or five seconds,
00:02:46.660 --> 00:02:48.390
or whatever you're
pulling into [inaudible].
00:02:48.390 --> 00:02:50.525
>> Sure, so instead of my
clients having to worry about.
00:02:50.525 --> 00:02:52.440
Hey, I need to check.
I need to check.
00:02:52.440 --> 00:02:54.765
Instead the server would be
like, oh, hey, it's ready,
00:02:54.765 --> 00:02:56.830
and I'll just give it
to you and here you go.
00:02:56.830 --> 00:02:58.320
Then, now on our side,
we can react
00:02:58.320 --> 00:03:01.340
to that event or that change
whenever it comes up.
00:03:01.340 --> 00:03:01.880
>> Yeah.
00:03:01.880 --> 00:03:03.520
>> Okay. That sounds
pretty good. Why don't we
00:03:03.520 --> 00:03:05.785
just start dive into demos
and see what it looks like.
00:03:05.785 --> 00:03:09.610
>> Yeah. So, here I have an
ASP.NET Core application
00:03:09.610 --> 00:03:11.280
pretty much a
vanilla ASP.NET Core
00:03:11.280 --> 00:03:13.765
application that I've
already add SignalR to.
00:03:13.765 --> 00:03:15.550
It happens to be
a chat application
00:03:15.550 --> 00:03:16.630
as I think we're required
00:03:16.630 --> 00:03:19.530
to have a chat application
whenever we demo SignalR.
00:03:19.530 --> 00:03:22.720
So, that's really the main piece
00:03:22.720 --> 00:03:24.580
that makes up
any SignalR application,
00:03:24.580 --> 00:03:26.625
which is a hub,
00:03:26.625 --> 00:03:28.420
which is really a class that has
00:03:28.420 --> 00:03:30.640
method's on it that
clients can call.
00:03:30.640 --> 00:03:31.110
>> Sure.
00:03:31.110 --> 00:03:34.110
>> So, here I have a
hub with a send method.
00:03:34.110 --> 00:03:36.715
So, whenever someone
types a message and sends
00:03:36.715 --> 00:03:40.330
a message it's gonna invoke
this method on the hub,
00:03:40.330 --> 00:03:42.455
and we're going to pass
on the message text.
00:03:42.455 --> 00:03:44.915
Then the more interesting
piece is that,
00:03:44.915 --> 00:03:47.110
inside the hub or a hub method,
00:03:47.110 --> 00:03:49.125
we have access to
this client's property,
00:03:49.125 --> 00:03:50.740
and then we actually address
00:03:50.740 --> 00:03:52.675
either all the connections or
00:03:52.675 --> 00:03:54.580
a subset of connections and then
00:03:54.580 --> 00:03:56.605
actually push
messages down to it.
00:03:56.605 --> 00:03:57.775
Here, I'm actually invoking
00:03:57.775 --> 00:04:01.435
a method on the clients
called New Message,
00:04:01.435 --> 00:04:03.300
and passing along
the sender information,
00:04:03.300 --> 00:04:06.730
and as well as the text
of the message.
00:04:06.730 --> 00:04:08.370
>> Right. So, when
you said client.
00:04:08.370 --> 00:04:09.450
Client can be anything.
00:04:09.450 --> 00:04:12.325
It could be a web browser,
it could be a Xamarin app,
00:04:12.325 --> 00:04:13.970
It could be
a desktop application.
00:04:13.970 --> 00:04:16.600
Client doesn't necessarily
mean it's a web thing, right?.
00:04:16.600 --> 00:04:17.250
>> Yeah. Absolutely.
00:04:17.250 --> 00:04:18.155
>> It can be anything.
00:04:18.155 --> 00:04:20.780
>> Yeah. So, typically
we start out with,
00:04:20.780 --> 00:04:22.010
most people start out with a
00:04:22.010 --> 00:04:23.905
JavaScript app that's
running in the browser.
00:04:23.905 --> 00:04:24.170
>> Yeah.
00:04:24.170 --> 00:04:27.720
>> But SignalR also has a
.NET SDK as you mentioned.
00:04:27.720 --> 00:04:29.155
So, we can actually use
that inside of Xamarin.
00:04:29.155 --> 00:04:29.765
>> Sure.
00:04:29.765 --> 00:04:31.765
>> We're also working on Java
00:04:31.765 --> 00:04:34.760
and C# clients,
sorry C++ clients.
00:04:34.760 --> 00:04:36.370
>> C++ Got it. Okay, cool.
00:04:36.370 --> 00:04:36.840
>> Yeah.
00:04:36.840 --> 00:04:38.680
>> So, let's see where
you actually wire it up.
00:04:38.680 --> 00:04:41.395
This is the hub, but
where do I actually say,
00:04:41.395 --> 00:04:43.550
hey ASP.NET, I want
00:04:43.550 --> 00:04:45.560
you to enable
my SignalR functionality.
00:04:45.560 --> 00:04:47.340
>> Yeah. Sounds good.
00:04:47.340 --> 00:04:50.230
So, as with most
things in ASP.NET,
00:04:50.230 --> 00:04:53.245
we would do this in
the start of CS.
00:04:53.245 --> 00:04:55.810
So, here you can see
that I am just calling
00:04:55.810 --> 00:04:58.720
one line of code
Services.AddSignalR.
00:04:58.720 --> 00:05:01.785
This adds all the
services that needed
00:05:01.785 --> 00:05:05.585
for SignalR to run into
the IoC container.
00:05:05.585 --> 00:05:09.785
Then down here I'm actually
running app.UseSignalR,
00:05:09.785 --> 00:05:12.400
and that adds the middleware
that's required to,
00:05:12.400 --> 00:05:14.310
that actually lights up
SignalR in our application.
00:05:14.310 --> 00:05:19.240
We're letting SignalR know
00:05:19.240 --> 00:05:21.640
about the different hubs that
we have in our application.
00:05:21.640 --> 00:05:23.585
Here we we only have
one hub named Chat,
00:05:23.585 --> 00:05:26.305
and we're mapping it to
a route named /chat.
00:05:26.305 --> 00:05:28.240
>> So, pretty much if I
had more than one hub
00:05:28.240 --> 00:05:29.850
and have more than
one routes per hub.
00:05:29.850 --> 00:05:31.045
Is that how it works?
00:05:31.045 --> 00:05:31.510
>> Yeah.
00:05:31.510 --> 00:05:32.290
>> Okay.
00:05:32.290 --> 00:05:37.360
>> So, I think the last thing
that we want to show you
00:05:37.360 --> 00:05:39.250
before we actually run the app is
00:05:39.250 --> 00:05:42.145
the client side JavaScript
that connects to the hub.
00:05:42.145 --> 00:05:43.560
>> Oh yeah, sure. Let's
take a look at that.
00:05:43.560 --> 00:05:44.850
>> So, this happens to be
00:05:44.850 --> 00:05:46.050
a vjs application but it could
00:05:46.050 --> 00:05:47.720
be using any
JavaScript framework,
00:05:47.720 --> 00:05:49.870
or just Minola JavaScript
if you want it to.
00:05:49.870 --> 00:05:52.810
The main couple of
pieces is that,
00:05:52.810 --> 00:05:54.520
you can see here
that I'm pulling in
00:05:54.520 --> 00:05:58.455
the SignalR client library
in JavaScript from a CDN.
00:05:58.455 --> 00:06:02.505
You can also pull it in
from npm if you want to.
00:06:02.505 --> 00:06:04.575
Then the key piece here is that,
00:06:04.575 --> 00:06:05.910
to establish a connection,
00:06:05.910 --> 00:06:07.780
it's just a couple lines of code.
00:06:07.780 --> 00:06:14.740
Here I'm saying, build
hub connection with URL/chat.
00:06:14.740 --> 00:06:15.890
Here you see that I'm wiring
00:06:15.890 --> 00:06:19.185
up a function
basically to listen to
00:06:19.185 --> 00:06:26.345
the new message event that
can be booked by the server,
00:06:26.345 --> 00:06:29.455
and I'm writing some code,
or running some code.
00:06:29.455 --> 00:06:31.160
Lastly, I am running
00:06:31.160 --> 00:06:33.830
connection.start that
actually starts a connection
00:06:33.830 --> 00:06:36.370
and then when
the connection has been
00:06:36.370 --> 00:06:37.600
established I'm just
basically telling
00:06:37.600 --> 00:06:39.280
the page that it's ready,
00:06:39.280 --> 00:06:40.120
and then it lights up
00:06:40.120 --> 00:06:41.610
the UI so that we
can actually start.
00:06:41.610 --> 00:06:43.930
>> So, we walk through
the steps really quickly.
00:06:43.930 --> 00:06:46.280
It's pulling the
signal on client,
00:06:46.280 --> 00:06:48.990
I create a connection,
and then I say,
00:06:48.990 --> 00:06:50.150
these are the messages
or these are
00:06:50.150 --> 00:06:51.940
the events that I
want to subscribe to.
00:06:51.940 --> 00:06:53.620
I give it the actions that I
00:06:53.620 --> 00:06:55.365
want to have to
those different methods,
00:06:55.365 --> 00:06:57.045
and then I say, well start.
00:06:57.045 --> 00:06:59.360
Now, asynchronously, it will
00:06:59.360 --> 00:07:01.810
just listen for those messages
and as they come in,
00:07:01.810 --> 00:07:02.970
they'll just react to them based
00:07:02.970 --> 00:07:04.295
on whatever code it is
that you just wrote.
00:07:04.295 --> 00:07:07.850
>> Yeah. So, let's go ahead
and start this application.
00:07:13.570 --> 00:07:18.120
It should open up in
the browser in a moment.
00:07:20.230 --> 00:07:23.990
Here it is. It's
a very simple chat application.
00:07:23.990 --> 00:07:28.525
If I just type, "Hey, Cecil",
it'll show up right away.
00:07:28.525 --> 00:07:30.430
You can see that I'm
00:07:30.430 --> 00:07:32.120
actually logged into
this application.
00:07:32.120 --> 00:07:35.085
So, SignalR chat has
the same context,
00:07:35.085 --> 00:07:38.840
in terms of the ASP.NET
identity information.
00:07:38.840 --> 00:07:40.780
So, you can actually reach into
00:07:40.780 --> 00:07:42.180
that context and find
00:07:42.180 --> 00:07:43.410
out who you are if
you're logged in.
00:07:43.410 --> 00:07:47.000
Now, let's quickly open up
another browser to show you
00:07:47.000 --> 00:07:48.340
that this is actually
real time and it's
00:07:48.340 --> 00:07:51.660
actually happening
across browsers.
00:07:53.050 --> 00:07:56.075
Here, I'm going to say, "Hi!"
and it shows up in both,
00:07:56.075 --> 00:07:58.830
and I happen to be not
logged in this case.
00:07:58.830 --> 00:08:01.815
So, I'm actually
seeing anonymous here.
00:08:01.815 --> 00:08:04.305
>> Cool. That's pretty
good. So, pretty easily,
00:08:04.305 --> 00:08:05.990
I can bring in the NuGet Package,
00:08:05.990 --> 00:08:07.650
I'm guessing on the .NET site.
00:08:07.650 --> 00:08:09.055
>> Yeah. You actually
don't have to do that,
00:08:09.055 --> 00:08:10.300
because it's actually part
00:08:10.300 --> 00:08:15.365
of the app package
that's brought in.
00:08:15.365 --> 00:08:16.235
>> By default?
00:08:16.235 --> 00:08:19.399
>> Yeah, by default in an
ASP.NET Core application,
00:08:19.399 --> 00:08:21.910
2.1 application. So, this
particular line here,
00:08:21.910 --> 00:08:25.130
it's a meta-package, and it
includes basically everything
00:08:25.130 --> 00:08:27.570
that Microsoft produces.
00:08:27.570 --> 00:08:28.230
>> Except in that release.
00:08:28.230 --> 00:08:28.635
>> Yeah.
00:08:28.635 --> 00:08:29.245
>> Got it.
00:08:29.245 --> 00:08:31.330
>> So, it's a SignalR
happens to be in there.
00:08:31.330 --> 00:08:33.700
>> So, then from
a.NET perspective,
00:08:33.700 --> 00:08:35.210
or from an ASP.NET
Core perspective,
00:08:35.210 --> 00:08:37.660
I don't really have to do
anything, other than say,
00:08:37.660 --> 00:08:40.350
inside of my startup
at CS, I had SignalR,
00:08:40.350 --> 00:08:41.960
I use SignalR, map my route,
00:08:41.960 --> 00:08:44.535
create the hub, and then
we get going, right?
00:08:44.535 --> 00:08:44.925
>> Yeah.
00:08:44.925 --> 00:08:46.120
>> Cool, that's
sounds pretty good.
00:08:46.120 --> 00:08:46.775
>> Yeah.
00:08:46.775 --> 00:08:48.690
>> Now, let's talk about,
00:08:48.690 --> 00:08:49.910
you are just running this in your
00:08:49.910 --> 00:08:50.970
machine, and then, obviously,
00:08:50.970 --> 00:08:52.050
it's just your single machine,
00:08:52.050 --> 00:08:53.470
you don't have a ton of users,
00:08:53.470 --> 00:08:55.300
that are hitting you and
hammering you. Right?
00:08:55.300 --> 00:08:55.570
>> Yeah.
00:08:55.570 --> 00:08:57.410
>> What happens when it's
00:08:57.410 --> 00:08:59.630
time for us to scale some
of these connections up?
00:08:59.630 --> 00:09:02.400
What are some of
the strategies that we use
00:09:02.400 --> 00:09:05.130
to do that with SignalR
as it is right now?
00:09:05.130 --> 00:09:07.485
>> Yeah. Great question. So,
I have a couple of slides
00:09:07.485 --> 00:09:11.380
to demonstrate how
scaling works in SignalR.
00:09:11.380 --> 00:09:13.380
So, here's a picture of
00:09:13.380 --> 00:09:15.220
what's happening right
now with our application.
00:09:15.220 --> 00:09:16.760
We have one instance,
happens to have run
00:09:16.760 --> 00:09:18.825
on my machine, can
run in the Cloud.
00:09:18.825 --> 00:09:20.950
We have one or more
clients connected
00:09:20.950 --> 00:09:23.105
to it. Pretty straightforward.
00:09:23.105 --> 00:09:24.100
But, what happens to
00:09:24.100 --> 00:09:25.520
the actual scale of
your application?
00:09:25.520 --> 00:09:28.275
Right? So, if you have
more than one version
00:09:28.275 --> 00:09:30.390
or instance of
the application running,
00:09:30.390 --> 00:09:33.315
you can have clients
connected to either instance.
00:09:33.315 --> 00:09:35.865
In this case, when
00:09:35.865 --> 00:09:39.155
instance one wants to broadcast
messages to all clients,
00:09:39.155 --> 00:09:41.445
it only knows about the clients
that are connected to it.
00:09:41.445 --> 00:09:43.870
Doesn't know about any other
instances they're running.
00:09:43.870 --> 00:09:47.605
So, with SignalR in really
any real time framework,
00:09:47.605 --> 00:09:50.785
there's usually an ability
to add on a Backplane,
00:09:50.785 --> 00:09:53.375
which allows different instances
00:09:53.375 --> 00:09:56.095
of SignalR running to
talk to each other,
00:09:56.095 --> 00:09:58.220
so that it can do things like
00:09:58.220 --> 00:10:00.840
send messages to all connections.
00:10:00.840 --> 00:10:02.330
>> So, the job of the Backplane
00:10:02.330 --> 00:10:04.660
essentially to propagates that
00:10:04.660 --> 00:10:07.680
connection information between
those different instances
00:10:07.680 --> 00:10:09.475
of SignalR that's
running pretty much?
00:10:09.475 --> 00:10:12.200
>> Yeah. SignalR Core
or ASP.NET Core,
00:10:12.200 --> 00:10:13.880
SignalR, we laid out,
00:10:13.880 --> 00:10:15.755
we support Redis, and so uses
00:10:15.755 --> 00:10:18.715
Redis pops up to fulfill
this functionality.
00:10:18.715 --> 00:10:20.495
>> So, is that package
00:10:20.495 --> 00:10:22.030
also available to
that meta-package
00:10:22.030 --> 00:10:22.830
too or that's
something [inaudible]?
00:10:22.830 --> 00:10:24.135
>> I'm going to believe
that we will put it in,
00:10:24.135 --> 00:10:25.615
as a separate meta-package.
00:10:25.615 --> 00:10:25.995
>> Got it.
00:10:25.995 --> 00:10:28.250
>> But, that's really just
pull it in and then enable it,
00:10:28.250 --> 00:10:30.155
or just basically
a couple lines of code,
00:10:30.155 --> 00:10:31.945
and then it starts
using a Backplane.
00:10:31.945 --> 00:10:33.320
>> Got it. So, how easy is
00:10:33.320 --> 00:10:34.780
this Backplane for
me to set up, right?
00:10:34.780 --> 00:10:37.530
Because I'm guessing as
my application starts
00:10:37.530 --> 00:10:39.030
to scale up and now we
00:10:39.030 --> 00:10:41.200
have these multiple
instances of SignalR,
00:10:41.200 --> 00:10:43.010
I got to create,
00:10:43.010 --> 00:10:45.300
I guess, my Redis connection
or my Redis servers.
00:10:45.300 --> 00:10:45.570
>> Yeah.
00:10:45.570 --> 00:10:46.450
>> I've got to plug that
00:10:46.450 --> 00:10:47.610
in and I'm sure I
got to have to do
00:10:47.610 --> 00:10:49.975
with metrics and monitoring
on that as well, right?
00:10:49.975 --> 00:10:51.900
>> Yeah. So, you
00:10:51.900 --> 00:10:53.760
do have to set up
your own Redis instance,
00:10:53.760 --> 00:10:55.200
and typically you want to set
00:10:55.200 --> 00:10:56.685
up in a way that is
highly available?
00:10:56.685 --> 00:10:57.135
>> Yeah.
00:10:57.135 --> 00:10:58.910
>> So, Azure is
an easy way of doing that.
00:10:58.910 --> 00:11:00.030
You just go to Azure
and say, "Hey,
00:11:00.030 --> 00:11:02.490
give me a Redis cluster
00:11:02.490 --> 00:11:05.185
basically that is
highly available,
00:11:05.185 --> 00:11:07.950
and then you supply the
connection string to SignalR,
00:11:07.950 --> 00:11:10.985
and that works fine.
00:11:10.985 --> 00:11:13.290
But, there's a couple
of other issues
00:11:13.290 --> 00:11:15.745
about a round rolling this,
00:11:15.745 --> 00:11:18.160
like implementing
the scale yourself.
00:11:18.160 --> 00:11:20.560
Another is that you
can see here that
00:11:20.560 --> 00:11:22.040
the clients are
actually connected
00:11:22.040 --> 00:11:23.500
to one specific instance,
00:11:23.500 --> 00:11:25.710
and forcing all to work properly,
00:11:25.710 --> 00:11:28.085
the clients need to always
connect to the same instance.
00:11:28.085 --> 00:11:30.190
So, you need to actually set up
00:11:31.090 --> 00:11:33.190
in front of the application.
00:11:33.190 --> 00:11:35.630
You also want to set
up sticky sessions,
00:11:35.630 --> 00:11:37.750
so that your clients
are always talking
00:11:37.750 --> 00:11:40.235
about to the same servers
for this to work properly.
00:11:40.235 --> 00:11:41.540
>> Is that something
that's pretty
00:11:41.540 --> 00:11:42.840
easy to set up or is that?
00:11:42.840 --> 00:11:44.990
>> It is. So, you have
to basically work with
00:11:44.990 --> 00:11:47.630
the whatever load balancer
you have and been using-
00:11:47.630 --> 00:11:48.210
>> Got it.
00:11:48.210 --> 00:11:51.090
>> -to make that happen,
or if you're using
00:11:51.090 --> 00:11:54.105
your Azure Web apps use to
flip a switch and says.
00:11:54.105 --> 00:11:55.410
>> Enabling the sessions.
00:11:55.410 --> 00:11:57.005
>> Yeah, give me a session
Affinity and is there.
00:11:57.005 --> 00:11:58.335
>> Got it.
00:11:58.335 --> 00:12:01.950
>> But, there's an easy way
to do this and that leads us
00:12:01.950 --> 00:12:05.640
into SignalR Service in Azure.
00:12:06.000 --> 00:12:08.360
So, this is like another view of
00:12:08.360 --> 00:12:10.175
the application that
we have right now.
00:12:10.175 --> 00:12:12.100
You can see that
both Web traffic and
00:12:12.100 --> 00:12:14.495
SignalR traffic talk
to the same instance,
00:12:14.495 --> 00:12:15.800
basically, the same applications.
00:12:15.800 --> 00:12:17.580
But, quite often you
00:12:17.580 --> 00:12:19.510
have perhaps the app also
00:12:19.510 --> 00:12:21.895
has a Web API that's heavily hit,
00:12:21.895 --> 00:12:23.420
or maybe you want to
00:12:23.420 --> 00:12:25.945
support like a lot of
connections in SignalR.
00:12:25.945 --> 00:12:27.160
>> Yeah.
00:12:27.390 --> 00:12:29.530
>> When you're scaling
your application,
00:12:29.530 --> 00:12:31.455
you have to scale both of these,
00:12:31.455 --> 00:12:33.090
when really what you
want is you want
00:12:33.090 --> 00:12:35.740
to scale them all independently.
00:12:37.630 --> 00:12:41.380
So, a couple months ago, we came
00:12:41.380 --> 00:12:43.955
up with a new service called
Azure SignalR Service,
00:12:43.955 --> 00:12:46.154
that allows to decouple
00:12:46.154 --> 00:12:50.690
the connections from the
ASP.NET Core application.
00:12:50.690 --> 00:12:53.590
So, that now, clients
actually connect to
00:12:53.590 --> 00:12:58.395
the SignalR Service for
their SignalR connections,
00:12:58.395 --> 00:13:01.750
but you can still hit
the regular Website other
00:13:01.750 --> 00:13:06.065
than ASP.NET Web app
for their Web traffic.
00:13:06.065 --> 00:13:08.990
So, quite often if
you just want to
00:13:08.990 --> 00:13:10.990
support say a thousand
00:13:10.990 --> 00:13:12.530
or a few thousand
SignalR connections,
00:13:12.530 --> 00:13:13.710
you set up the scale
of the connection,
00:13:13.710 --> 00:13:15.130
but you can still have
00:13:15.130 --> 00:13:17.260
just one instance of the app
running if you wanted to.
00:13:17.260 --> 00:13:19.560
>> Okay. So, now
instead of me managing
00:13:19.560 --> 00:13:20.750
that Redis cluster or
00:13:20.750 --> 00:13:22.455
whatever I'm using
for my Backplane,
00:13:22.455 --> 00:13:24.790
I could just use,
00:13:24.790 --> 00:13:26.815
I could put my apps in
the SignalR Service.
00:13:26.815 --> 00:13:27.125
>> Yeah.
00:13:27.125 --> 00:13:30.070
>> Now, this is again a managed
service that's there to
00:13:30.070 --> 00:13:32.110
handle that Backplane and handle
00:13:32.110 --> 00:13:33.080
some of those connections for me,
00:13:33.080 --> 00:13:34.100
so I don't have to
worry about that.
00:13:34.100 --> 00:13:36.460
>> So, all this stuff,
running the Backplane,
00:13:36.460 --> 00:13:39.675
sticky shut sessions, all that
stuff is managed for you.
00:13:39.675 --> 00:13:40.530
>> So, now, what do need to do
00:13:40.530 --> 00:13:42.175
that plug that into
my application?
00:13:42.175 --> 00:13:43.400
>> Hey, good question. So, let's
00:13:43.400 --> 00:13:44.510
see how we get to add that to
00:13:44.510 --> 00:13:46.910
our application that we've
been working at previously.
00:13:46.910 --> 00:13:53.760
So, let's go into
the Azure portal,
00:13:54.940 --> 00:13:56.900
and I'll quickly
show you how you can
00:13:56.900 --> 00:13:58.325
create a SignalR service.
00:13:58.325 --> 00:13:59.990
So, you actually go
into search here,
00:13:59.990 --> 00:14:05.695
just search for SignalR, click
"Create" for the service.
00:14:05.695 --> 00:14:06.530
There's actually not a lot of
00:14:06.530 --> 00:14:07.715
options that you have to supply.
00:14:07.715 --> 00:14:09.135
I usually give it a name.
00:14:09.135 --> 00:14:11.675
Choose a region, and then you
can choose a pricing tier.
00:14:11.675 --> 00:14:13.190
So, you can actually have
00:14:13.190 --> 00:14:15.295
a SignalR service
instance for free,
00:14:15.295 --> 00:14:17.850
supports up to 100 connections,
00:14:17.850 --> 00:14:19.735
or you can basically buy
00:14:19.735 --> 00:14:21.835
a thousand connections at a time,
00:14:21.835 --> 00:14:23.880
and with backed by SLA and
00:14:23.880 --> 00:14:27.260
a higher message board as well.
00:14:27.260 --> 00:14:29.870
Right now, in preview,
00:14:29.870 --> 00:14:32.390
we are allowing you to
scale up to 10 units,
00:14:32.390 --> 00:14:34.350
but hopefully by the time
we hit General Bill,
00:14:34.350 --> 00:14:36.760
we've got to scale up to
a lot more than 10 units.
00:14:36.760 --> 00:14:37.180
>> Okay.
00:14:37.180 --> 00:14:39.310
>> So, with 10 units, giving
you 10,000 connections.
00:14:39.310 --> 00:14:42.040
>> So, right now, if as
a developer hobbyist,
00:14:42.040 --> 00:14:43.215
so I'm just playing
around a little bit.
00:14:43.215 --> 00:14:44.815
I could just start off
with the free one.
00:14:44.815 --> 00:14:45.400
>> Yeah.
00:14:45.400 --> 00:14:46.875
>> Then, have it run
my applications and
00:14:46.875 --> 00:14:48.875
test out what that
scale up feels like.
00:14:48.875 --> 00:14:49.180
>> Yeah.
00:14:49.180 --> 00:14:50.505
>> Then, whenever
I'm ready to go to
00:14:50.505 --> 00:14:52.400
production or run
some heavier workloads,
00:14:52.400 --> 00:14:53.930
I could switch over
to a higher tier,
00:14:53.930 --> 00:14:56.370
standard, or get more units
or something like that.
00:14:56.370 --> 00:14:56.895
>> Yeah.
00:14:56.895 --> 00:14:57.360
>> Okay.
00:14:57.360 --> 00:15:00.410
>> So, I've already have
an instance created,
00:15:00.410 --> 00:15:01.790
so you want to watch me create
00:15:01.790 --> 00:15:04.535
one and wait for it to come up.
00:15:04.535 --> 00:15:07.450
>> Another thing I noticed
that it says there and even
00:15:07.450 --> 00:15:10.010
says this on the screen as
well, it says "Preview".
00:15:10.010 --> 00:15:12.070
So, does that mean
that we're not ready
00:15:12.070 --> 00:15:15.040
for primetime yet
or what does mean?
00:15:15.040 --> 00:15:18.025
>> Yeah. So, as with a lot
of previews in Azure,
00:15:18.025 --> 00:15:22.175
is for developers and customers
to go and try it out.
00:15:22.175 --> 00:15:23.100
>> Okay.
00:15:23.100 --> 00:15:25.140
>> I've been using
00:15:25.140 --> 00:15:26.535
this for a while, it
works pretty well.
00:15:26.535 --> 00:15:28.420
Hopefully, pretty
soon we'll be able
00:15:28.420 --> 00:15:31.150
to release it in
general availability.
00:15:31.150 --> 00:15:32.570
>> Got you.
00:15:32.620 --> 00:15:35.570
>> So here, it's
00:15:35.570 --> 00:15:37.750
a pretty standard kind
of Azure kind of portal,
00:15:37.750 --> 00:15:40.450
you can see some metrics
in our application.
00:15:40.450 --> 00:15:43.340
You can also kind
of see keys here,
00:15:43.340 --> 00:15:45.105
you can scale up, and scale out.
00:15:45.105 --> 00:15:46.550
What I'm going to do here
is I'm actually going
00:15:46.550 --> 00:15:50.935
to grab that connection string,
00:15:50.935 --> 00:15:54.800
and we're going to add
this to our application.
00:15:54.800 --> 00:15:57.250
So, the first thing that
we have to do is add
00:15:57.250 --> 00:16:01.335
a package to our NuGet package
to our application.
00:16:01.335 --> 00:16:04.040
So, I only have one
here that's commented.
00:16:04.040 --> 00:16:07.220
I'll uncomment it and save it,
00:16:07.220 --> 00:16:10.690
and that's really
all we need to do.
00:16:10.690 --> 00:16:12.130
So, we're bringing
in the Azure.SignalR
00:16:12.130 --> 00:16:15.630
package and there's
only two lines of code that we
00:16:15.630 --> 00:16:17.025
have to add in order to
00:16:17.025 --> 00:16:21.895
enable Azure in our service
in our application.
00:16:21.895 --> 00:16:25.740
So, we'll go back
to our startup.cs,
00:16:25.740 --> 00:16:28.950
and at this line,
00:16:28.950 --> 00:16:32.145
we're adding
the SignalR Services I
00:16:32.145 --> 00:16:33.660
will also go ahead and add on the
00:16:33.660 --> 00:16:35.680
Azure.SignalR Services as well.
00:16:35.680 --> 00:16:39.650
So it's the first line that
we have to change and now,
00:16:39.650 --> 00:16:40.955
the second line that
we have to change
00:16:40.955 --> 00:16:42.395
is instead of saying UseSignalR,
00:16:42.395 --> 00:16:45.590
we are going to use
Azure.SignalR, and that's it.
00:16:45.590 --> 00:16:48.765
So, and the other thing is,
00:16:48.765 --> 00:16:50.020
you might be wondering,
00:16:50.020 --> 00:16:51.520
how does it know about
the connection string.
00:16:51.520 --> 00:16:51.820
>> Yes.
00:16:51.820 --> 00:16:53.440
>> We have to give it
to connection string.
00:16:53.440 --> 00:16:54.675
So, we can pass it here,
00:16:54.675 --> 00:16:56.900
or we can set
environment variable.
00:16:57.100 --> 00:16:59.720
Just to keep it as
easy as it basically,
00:16:59.720 --> 00:17:01.580
does a hard code in
our application right now.
00:17:01.580 --> 00:17:02.720
>> Sure.
00:17:02.720 --> 00:17:06.180
>> Now, when we run
the application.
00:17:09.650 --> 00:17:12.270
>> So now, I'm expecting
what's going to happen is
00:17:12.270 --> 00:17:14.275
that instead of it
just routing locally,
00:17:14.275 --> 00:17:15.080
it's going to go out and
00:17:15.080 --> 00:17:16.290
connect to Azure
and it's going to
00:17:16.290 --> 00:17:18.365
use and signal as my back plate?
00:17:18.365 --> 00:17:18.700
>> Yes.
00:17:18.700 --> 00:17:19.810
>> So, now hopefully
we should be able to
00:17:19.810 --> 00:17:21.340
scale to a lot more users
00:17:21.340 --> 00:17:24.020
than just you and
the other browser.
00:17:24.020 --> 00:17:24.205
>> Yeah.
00:17:24.205 --> 00:17:25.250
>> Now, you're talking
to your machine.
00:17:25.250 --> 00:17:27.080
>> Yes. So, we'd type hi here.
00:17:27.080 --> 00:17:28.425
It still works.
00:17:28.425 --> 00:17:29.645
It all still works.
00:17:29.645 --> 00:17:30.255
>> Yeah.
00:17:30.255 --> 00:17:32.070
>> So, the only way to really
tell that you're actually
00:17:32.070 --> 00:17:34.080
running against the service is if
00:17:34.080 --> 00:17:38.530
we actually go into the
"Developer Tools" in the browser,
00:17:38.530 --> 00:17:40.185
and we can see down
here that it's
00:17:40.185 --> 00:17:42.370
actually connecting to
our service instance.
00:17:42.370 --> 00:17:43.095
>> That's true.
00:17:43.095 --> 00:17:44.580
>> If we go back
over to the portal,
00:17:44.580 --> 00:17:46.660
would we be able to
see any connectivity
00:17:46.660 --> 00:17:48.300
or any metrics or
anything like that?
00:17:48.300 --> 00:17:49.600
>> Yeah, probably in
a couple minutes.
00:17:49.600 --> 00:17:51.480
I'm not sure if it actually
happens right away,
00:17:51.480 --> 00:17:53.550
but what you would
expect is if it
00:17:53.550 --> 00:17:55.250
was trying to see
little spikes like this.
00:17:55.250 --> 00:17:56.430
>> Okay. I got you.
00:17:56.430 --> 00:17:56.685
>> Yes.
00:17:56.685 --> 00:17:58.140
>> I noticed at the top,
you could see "Show
00:17:58.140 --> 00:17:59.560
Data" for an hour or six hours.
00:17:59.560 --> 00:17:59.740
>> Right.
00:17:59.740 --> 00:18:01.590
>> So, there's some a little bit
of delay but eventually,
00:18:01.590 --> 00:18:03.850
that data would populate and
you'll be able to see that.
00:18:03.850 --> 00:18:06.050
>> Yeah, got it.
00:18:06.190 --> 00:18:08.920
>> Okay. So now, we saw
how we could kind of
00:18:08.920 --> 00:18:11.495
plug my existing app inside of,
00:18:11.495 --> 00:18:13.825
to use Azure signal
as my back plate.
00:18:13.825 --> 00:18:17.480
But now, what if I had
like a non-.NET core
00:18:17.480 --> 00:18:21.170
application or non traditional
single core application,
00:18:21.170 --> 00:18:23.005
and I wanted to plug in my,
00:18:23.005 --> 00:18:24.800
I don't know, like my JavaScript
00:18:24.800 --> 00:18:26.055
application or
something like that?
00:18:26.055 --> 00:18:28.740
Do we have another way
that they can kind of
00:18:28.740 --> 00:18:30.130
come in and kind of plug in
00:18:30.130 --> 00:18:31.650
and kind of play together
in the same space?
00:18:31.650 --> 00:18:34.500
>> Yes, we actually hear
this question a lot,
00:18:34.530 --> 00:18:36.180
and that actually leads
00:18:36.180 --> 00:18:37.955
us really well into
the next topic.
00:18:37.955 --> 00:18:38.525
>> Okay.
00:18:38.525 --> 00:18:40.220
>> So, a couple of questions
00:18:40.220 --> 00:18:41.660
that we typically
get are how do we
00:18:41.660 --> 00:18:43.940
integrate Azure SignalR Service
00:18:43.940 --> 00:18:46.235
really easily with
other Azure services?
00:18:46.235 --> 00:18:46.925
>> Yes.
00:18:46.925 --> 00:18:48.845
>> Also, how do we get
00:18:48.845 --> 00:18:52.545
the SignalR goodness into
other languages as well?
00:18:52.545 --> 00:18:54.670
Thankfully, there's
a service in Azure that
00:18:54.670 --> 00:18:56.690
works really well with
other Azure services
00:18:56.690 --> 00:18:58.240
and supports mobile languages and
00:18:58.240 --> 00:19:00.890
that is Azure Functions.
00:19:00.890 --> 00:19:01.595
>> Okay.
00:19:01.595 --> 00:19:06.560
>> So, what we have built is
an Azure Functions binding
00:19:06.560 --> 00:19:08.270
for SignalR that allows
00:19:08.270 --> 00:19:11.735
you to really easily output
messages to a SignalR hub,
00:19:11.735 --> 00:19:13.745
so that and effectively
00:19:13.745 --> 00:19:15.780
replaces the logic
that it would have
00:19:15.780 --> 00:19:17.490
been running inside of NHP core
00:19:17.490 --> 00:19:19.980
application for
talking to the hub,
00:19:19.980 --> 00:19:21.890
so they can run
this effortlessly.
00:19:21.890 --> 00:19:23.900
>> Cool. So, let's take
a look at this model.
00:19:23.900 --> 00:19:25.505
Let's see how this kind
of plugs together.
00:19:25.505 --> 00:19:30.115
>> Yes, you bet. So, I have
an application right here.
00:19:30.115 --> 00:19:31.760
So, I think the best thing
to do is actually
00:19:31.760 --> 00:19:33.425
try to run this
application first.
00:19:33.425 --> 00:19:34.360
>> Okay.
00:19:34.360 --> 00:19:36.460
>> So, what does
this application do right now?
00:19:36.460 --> 00:19:37.440
Is this the same when
you were running
00:19:37.440 --> 00:19:38.500
before or is this something?
00:19:38.500 --> 00:19:40.585
>> This is something different
so no more shut ups.
00:19:40.585 --> 00:19:44.215
So, I'm going to F5
this application right now,
00:19:44.215 --> 00:19:47.190
and this starts up
the Azure function host.
00:19:47.190 --> 00:19:49.190
So, it's an Azure
function project
00:19:49.190 --> 00:19:51.080
that's running locally
on my machine,
00:19:51.080 --> 00:19:52.430
and the other thing
I need to do is
00:19:52.430 --> 00:19:54.690
actually open up this web page.
00:19:55.000 --> 00:19:57.170
Looks like it's
already have running,
00:19:57.170 --> 00:19:59.580
so we let me open it again.
00:20:07.660 --> 00:20:11.915
So, it's a really simple kind
of flight prices.
00:20:11.915 --> 00:20:12.625
>> Sure.
00:20:12.625 --> 00:20:15.170
>> Each one of these prices
are pulling from
00:20:15.170 --> 00:20:17.745
a document inside
of the Cosmos DB
00:20:17.745 --> 00:20:21.970
and we're able to
update this live when
00:20:21.970 --> 00:20:26.750
an update is made to a document
inside of the Cosmos DB.
00:20:26.750 --> 00:20:29.600
>> So, how does that
information kind
00:20:29.600 --> 00:20:30.940
of flow all the
way around, right?
00:20:30.940 --> 00:20:31.180
>> Yeah.
00:20:31.180 --> 00:20:33.350
>> So, I have Cosmos DB
and Cosmos DB
00:20:33.350 --> 00:20:35.745
works on the concept
of collections.
00:20:35.745 --> 00:20:36.040
>> Yes.
00:20:36.040 --> 00:20:37.510
>> Right? So, I have
a Cosmos DB collection,
00:20:37.510 --> 00:20:38.695
I have inserted a record.
00:20:38.695 --> 00:20:41.495
How does that go from triggering
00:20:41.495 --> 00:20:43.550
a signal or notification
00:20:43.550 --> 00:20:45.055
all the way over
into the browser?
00:20:45.055 --> 00:20:46.750
>> Yes, so I'm actually showing
00:20:46.750 --> 00:20:48.240
you the Azure Function
that actually does this.
00:20:48.240 --> 00:20:49.910
So, we're using
Azure Functions to integrate
00:20:49.910 --> 00:20:52.090
the Cosmos DB Change Feed.
00:20:52.090 --> 00:20:52.795
>> Okay.
00:20:52.795 --> 00:20:55.285
>> With signal in our service,
00:20:55.285 --> 00:20:58.215
it actually broadcast
these events when they happen.
00:20:58.215 --> 00:20:59.850
So here, we can see
00:20:59.850 --> 00:21:02.255
a function called
"OnDocumentChanged".
00:21:02.255 --> 00:21:04.605
I will quickly take a look
at the function of JSON,
00:21:04.605 --> 00:21:06.050
which describes the bindings
00:21:06.050 --> 00:21:07.530
that are available
to the function.
00:21:07.530 --> 00:21:07.900
>> Sure.
00:21:07.900 --> 00:21:09.160
>> So, the first binding you'll
00:21:09.160 --> 00:21:11.065
see is the cosmosDBTrigger.
00:21:11.065 --> 00:21:12.510
So, we're telling it to
00:21:12.510 --> 00:21:15.310
watch a collection
named "flights",
00:21:15.310 --> 00:21:17.505
and whenever there's a change,
00:21:17.505 --> 00:21:19.730
run this "Execute
this as Function",
00:21:19.730 --> 00:21:22.280
and I'm also adding
a second binding to it which is
00:21:22.280 --> 00:21:25.430
our SignalR open binding and that
00:21:25.430 --> 00:21:27.690
allows us to output messages to
00:21:27.690 --> 00:21:31.130
SignalR hub and named flights.
00:21:31.130 --> 00:21:34.115
So, with those two
things configured,
00:21:34.115 --> 00:21:36.290
we can take a look at
the function itself.
00:21:36.290 --> 00:21:38.400
So, this particular
function happens to
00:21:38.400 --> 00:21:41.035
run, it used JavaScript,
00:21:41.035 --> 00:21:44.305
but this could be C#, it
could be Java Python,
00:21:44.305 --> 00:21:48.135
anything else that functions B2.
00:21:48.135 --> 00:21:48.550
>> Yeah.
00:21:48.550 --> 00:21:51.170
>> Will support.
So, we can see here
00:21:51.170 --> 00:21:53.960
that the data that comes from
00:21:53.960 --> 00:21:55.790
the trigger is
passed directly into
00:21:55.790 --> 00:21:57.925
the the function itself
00:21:57.925 --> 00:22:00.110
that happens in the
documents that were changed.
00:22:00.110 --> 00:22:00.845
>> Yes.
00:22:00.845 --> 00:22:04.430
>> Here, I'm just
really quickly mapping
00:22:04.430 --> 00:22:08.445
the documents to an array
of SignalR message objects,
00:22:08.445 --> 00:22:12.650
and all that is
an object that indicates
00:22:12.650 --> 00:22:16.620
which event to raise
on the client,
00:22:16.620 --> 00:22:20.000
and also passing along
an argument and which is
00:22:20.000 --> 00:22:23.615
literally passing
the document as the argument.
00:22:23.615 --> 00:22:24.840
>> Yes.
00:22:26.460 --> 00:22:28.810
>> So now, we have an array of
00:22:28.810 --> 00:22:30.560
SignalR message objects which
00:22:30.560 --> 00:22:32.135
is a plain JavaScript objects,
00:22:32.135 --> 00:22:34.260
and we're assigning that to
00:22:34.260 --> 00:22:37.350
an open binding SignalR
messages, and then that's it.
00:22:37.350 --> 00:22:39.060
That's the whole function itself.
00:22:39.060 --> 00:22:40.735
So, we've kind of connected the
00:22:40.735 --> 00:22:41.830
documents that came in from
00:22:41.830 --> 00:22:46.360
the trigger to
SignalR Service itself.
00:22:46.360 --> 00:22:49.120
So, that's going to get
broadcast to the application.
00:22:49.120 --> 00:22:51.290
>> So, how do we actually
get access to this binding?
00:22:51.290 --> 00:22:52.700
You talked about how it works,
00:22:52.700 --> 00:22:55.600
but is this a binding
that's already built into
00:22:55.600 --> 00:22:57.330
the Azure Functions SCK or is
00:22:57.330 --> 00:22:58.690
this something I have to bring
00:22:58.690 --> 00:23:00.155
in and kind of configure myself?
00:23:00.155 --> 00:23:01.830
>> Yes. So, you have
to bring this in.
00:23:01.830 --> 00:23:04.505
So, with Azure Functions v2,
00:23:04.505 --> 00:23:05.935
we've actually moved a lot
00:23:05.935 --> 00:23:07.480
of the bindings that used to come
00:23:07.480 --> 00:23:11.000
with the functions run
time in v1 outside,
00:23:11.000 --> 00:23:12.770
so we can kind of just pick
00:23:12.770 --> 00:23:15.020
and choose the extra bindings
we want to bring in.
00:23:15.020 --> 00:23:18.065
Cosmos DB is one and also
00:23:18.065 --> 00:23:21.680
the SignalR binding is another
that you can bring in.
00:23:21.680 --> 00:23:21.995
>> Okay.
00:23:21.995 --> 00:23:24.170
>> So, the Function CLI gives
00:23:24.170 --> 00:23:27.055
you a fairly easy way
to bring the those in.
00:23:27.055 --> 00:23:32.710
The bindings are implemented
as extensions which are
00:23:32.710 --> 00:23:34.820
just really NuGet packages
00:23:34.820 --> 00:23:38.845
and the Function CLI has
an extensions command.
00:23:38.845 --> 00:23:40.055
So, you can actually go func
00:23:40.055 --> 00:23:42.510
extensions, install, I believe,
00:23:42.510 --> 00:23:45.200
and then a NuGet package
name and I should bring that
00:23:45.200 --> 00:23:48.440
in as a function or
as an extension.
00:23:48.440 --> 00:23:51.210
Then, once you do
that, the bindings are
00:23:51.210 --> 00:23:54.190
automatically there
for you to use.
00:23:54.190 --> 00:23:56.910
>> So then, we're also
be writing JavaScript's
00:23:56.910 --> 00:23:59.985
or .NETs or whatever other
language that Azure Functions,
00:23:59.985 --> 00:24:01.205
they too discuss and support.
00:24:01.205 --> 00:24:01.720
>> Yes.
00:24:01.720 --> 00:24:03.530
>> All I need to do is
bring it out NuGet package
00:24:03.530 --> 00:24:05.295
and it will work across
all these languages?
00:24:05.295 --> 00:24:05.615
>> Yes.
00:24:05.615 --> 00:24:06.145
>> Hopefully?
00:24:06.145 --> 00:24:06.950
>> Yes, that's the idea.
00:24:06.950 --> 00:24:08.385
>> Okay. Cool. Sounds good.
00:24:08.385 --> 00:24:10.655
>> Yes. So, let's just
quickly see this work.
00:24:10.655 --> 00:24:13.660
So, in our VS Code,
00:24:13.660 --> 00:24:16.940
you can actually pull
up documents that are
00:24:16.940 --> 00:24:20.420
in our Cosmos DB.
So, let's pick one.
00:24:20.420 --> 00:24:24.370
So, here's one, here's
a flight from Seattle to JFK.
00:24:24.370 --> 00:24:26.830
Let's say that we
wanted to change that
00:24:26.830 --> 00:24:28.885
to $99 and we save it.
00:24:28.885 --> 00:24:32.310
What we should see fairly
quickly is that the price
00:24:32.310 --> 00:24:35.820
will reflect on the client.
00:24:35.820 --> 00:24:37.090
>> Yes.
00:24:37.370 --> 00:24:39.910
>> This change is
going to Cosmos DB,
00:24:39.910 --> 00:24:41.830
it's going out to
the Cosmos DB Change Feed,
00:24:41.830 --> 00:24:44.410
it's triggering our function
and our function
00:24:44.410 --> 00:24:47.420
is broadcasting that
out on SignalR Service.
00:24:47.420 --> 00:24:50.440
>> So, we have real-time
all the way around, right?
00:24:50.440 --> 00:24:50.685
>> Yeah.
00:24:50.685 --> 00:24:51.965
>> We have real-time as in
00:24:51.965 --> 00:24:54.095
this push notifications
coming from the database.
00:24:54.095 --> 00:24:54.455
>> Yeah.
00:24:54.455 --> 00:24:56.250
>> There's push
notifications coming
00:24:56.250 --> 00:25:00.280
from our SignalR Service.
00:25:00.280 --> 00:25:00.705
>> Yeah.
00:25:00.705 --> 00:25:02.760
>> Then, there's also now,
like the client is now,
00:25:02.760 --> 00:25:04.410
just has to signal our client,
00:25:04.410 --> 00:25:05.970
just listening and
reacting to that.
00:25:05.970 --> 00:25:06.240
>> Yeah.
00:25:06.240 --> 00:25:07.960
So, it's all-around, it's
like real-time everywhere?
00:25:07.960 --> 00:25:08.080
>> Yes.
00:25:08.080 --> 00:25:09.450
>> Everybody gets real-time play?
00:25:09.450 --> 00:25:11.265
>> Yes, and basically
it's serverless too.
00:25:11.265 --> 00:25:12.000
>> Okay, awesome.
00:25:12.000 --> 00:25:13.850
>> So, you don't have to
manage any infrastructures.
00:25:13.850 --> 00:25:15.765
>> This is really
awesome, this is good.
00:25:15.765 --> 00:25:18.545
>> So, if I wanted to
get started with this,
00:25:18.545 --> 00:25:20.380
like where are some places
I could go to to get
00:25:20.380 --> 00:25:22.210
documentation or
watch some videos
00:25:22.210 --> 00:25:24.150
or kind of just learn
about it in general?
00:25:24.150 --> 00:25:26.065
>> Yes. So, I have
a bunch of links here.
00:25:26.065 --> 00:25:28.465
So, right now, the SignalR
00:25:28.465 --> 00:25:31.290
binding lives on
my GitHub account.
00:25:31.290 --> 00:25:31.540
>> Yeah.
00:25:31.540 --> 00:25:33.170
>> But we're in
the process of moving
00:25:33.170 --> 00:25:35.030
that over to
the Azure organization.
00:25:35.030 --> 00:25:35.430
>> Okay.
00:25:35.430 --> 00:25:38.070
>> So that becomes
an unofficial Microsoft Project.
00:25:38.070 --> 00:25:38.680
>> Got it.
00:25:38.680 --> 00:25:39.595
>> So, hopefully, that will
00:25:39.595 --> 00:25:41.435
happen in the next
couple of weeks.
00:25:41.435 --> 00:25:43.610
Maybe by the time
this video airs,
00:25:43.610 --> 00:25:49.145
you'll already be there but
we'll see how that goes.
00:25:49.145 --> 00:25:52.780
I also have the flight sample
on GitHub as well.
00:25:52.780 --> 00:25:54.720
I have another one that
we didn't get a chance to
00:25:54.720 --> 00:25:56.635
get to that uses
00:25:56.635 --> 00:25:59.900
a C# and durable
functions application
00:25:59.900 --> 00:26:01.285
to use the binding.
00:26:01.285 --> 00:26:02.465
>> Yeah.
00:26:02.465 --> 00:26:05.310
>> Lastly, you can find all about
00:26:05.310 --> 00:26:06.940
the Azure SignalR
Service by going to
00:26:06.940 --> 00:26:08.855
the website, on Azure.com.
00:26:08.855 --> 00:26:10.240
>> All right, great.
Thank you, man.
00:26:10.240 --> 00:26:11.570
Thank you so much for
coming in and talking
00:26:11.570 --> 00:26:13.365
to us all about SignalR.
This is really good.
00:26:13.365 --> 00:26:14.680
>> Awesome, thanks for having me.
00:26:14.680 --> 00:26:17.200
>> So, we just learned all
about using SignalR and
00:26:17.200 --> 00:26:18.510
also the Azure SignalR Service
00:26:18.510 --> 00:26:20.970
on this episode of
the ON.NET lecture.