[MUSIC]
>> Why would I want to use SignalR?
Why wouldn't I, especially with WebSockets being so prevalent,
just start programming WebSockets instead?
>> Have you ever programmed against WebSockets?
>> I have and it's a bit of a clunky experience.
>> SignalR is not. There's your first answer.
The second answer is,
you will find some clients and some servers out there who,
for instant reason here, don't support WebSockets.
Somebody might have an old browser.
It still happens, believe me.
Also, some lower-level devices
don't necessarily support WebSockets,
there are some smaller devices, watches, etc.
Who might not have first-class support for WebSockets.
In those cases, they would back off
and they would use something like Long poll.
I found that this usually works
better with a set of slides that I've brought,
which is not the pm move,
but do you mind if I pull up some slides?
>> Not at all, go for it.
>> Cool, let me hit this real quick and I've only got
two monitors and I think that's on the right monitor.
Feel free to just speak and interrupt me
because I won't see you, so that's fine.
>> Okay.
>> Real quick, a crash course in what SignalR is.
I'm going to go ahead and just click through a couple of slides.
This is your long polling idea.
In SignalR, the first thing we would
do is we would do a negotiation,
which this is all over the SignalR documentation,
I'll give you a link for that later.
Essentially what we do is the client will reach out
to the server and do a negotiate request.
The server, this being a core server,
will basically tell it whether or not it supports WebSockets.
If it doesn't support WebSockets,
what we do is we go ahead and we start off with long polling.
It's like WebSockets are
first and then will try server-sent events.
If either one of those don't work,
then we back off and we try long polling because long polling,
it's a request response model.
In long polling, essentially what happens is
this client will make a request to the server,
server is going to fire an event,
make a response, and then immediately
the client's going to make another request.
You've probably done this early
on before we had WebSockets before we had SignalR.
This is really like your meta-equipped refresh
or like a JavaScript refresh,
or you just make a series of Ajax calls and a schedule.
We've had to do this thing before.
At one point it got
better and we had the concept of server-sent events,
in which case you could just create a new event source.
Then whenever an event happens on the server,
it actually sends a message back out to the client.
If you don't have WebSockets, you want to have SSE,
but long polling is always going to be your all the way back off.
But in the perfect world,
your client and your server would both have
WebSockets and WebSockets basically what happens is,
you make that negotiate request.
The server says I support WebSockets. You're good.
The client says, "Cool. I'd like you to upgrade
this connection and make it a WebSocket connection."
The moment it does that,
it switches protocols to WebSockets
and now you're partying in real-time.
Now all the messages just continue to go back and forth.
Most times with your new browsers,
this is what you're going to see
because of the fact that most clients
and servers actually already support this experience.
One thing I'd like to point out though is,
it's always fun when you can see what you can do with it.
Let me show you just a silly little 3D demo that I've got here.
What I'll do is I'll pull open a quick little thing right
here and what I'll do is I'll drag this over
and I know you've got some JavaScript watchers out there.
You won't want to look at my JavaScript code in gratuitous detail,
I'm not that great at it. We'll get to that later.
But this is essentially a 3D rendering or a 3D series of images
stitched together using three.js those are
fantastic 3D JavaScript engine.
What I can do with this is go like this,
which is pretty neat, that looks great on the screen.
Basically, I have this pane here and the pane
shows all the different images around.
Essentially this is just a series of images
that get stitched altogether.
Now what I also have is a control panel and what I'll do is
I'll "Copy" this out and just
"Paste" this in and just go to Controls.
I'm not going to do it here because I
want you to be able to see what's going on on my screen.
What I'll do is I'll show you that I've actually
got that pulled up on my phone.
I don't know if you can see that very well,
but I've got to get the same thing and I've got an X,
Y, and Z slider.
What I'll do is now I'll grab one of those sliders,
let me refresh it and connect again.
Let me grab one of those sliders and you can see
as I move the X slider around,
we're actually spinning that on an x-axis.
When I spin the Y slider around,
we're spending it on the y-axis and
the JavaScript code that I have is old
enough that the gyroscope part no
longer works because a lot of those APIs have been deprecated.
I have to get back into the code and update that.
But eventually what I'll be able to do is show you how I
can take my phone and go like
this and that plane will move around.
But I'm using some old JavaScript APIs
in there that don't really exist anymore.
But what I can do is just pull
that other page back up again and what I can
do here is pull this off to
the side and we'll get a couple of these panels opened up.
I'll pull out one over here and just do a new browser right here.
What you'll see is that for each one of these connected clients,
whenever I use this control panel,
they're all going to map.
That's what SignalR is for,
it's for those interactive experiences where you've
got multiple browsers across multiple users,
they can be in different places like we are right now.
The idea is that you could actually
use SignalR so that when something happens,
when an event fires,
when somebody does a send or an envoke on this side,
we actually have code over here that literally looks like
on and then the event name and then how to process it.
If you've ever done a lower-level web socket programming,
you know that's not what it looks like.
This is a hyper simplification of that.
It's also something that you have to
give David and Damien a lot of respect.
They have this ability to seeing into the future.
One thing that David said at one point was,
"Do you think WebSockets is going to be the last thing?"
I was like, "Of course not."
He goes, "Well, if you're using SignalR it won't matter because
we'll just add whatever
the new thing is to it and it will keep working."
That's one of the reasons for SignalR.
In the early days it was because we lacked WebSockets support.
Today it's because WebSockets is probably not going to be
the last thing that we do to enable real time on the web.
If you're programming against SignalR
at the point where we add it in,
and I'm not saying that we're going to do this.
We just get that out there very quickly.
Just give you a random idea than not saying that we're doing this.
I've pitched it in the team room and they've throw things at me,
so I don't know if this will ever come.
But if you can imagine something like SignalR over gRPC, again,
not proposing that we're doing that or SignalR over
ACTP3 or whatever protocol gets embedded next month.
That's where the abstraction layer
of SignalR becomes pretty valuable.
At that point, you can do more stuff with it.