>> Hey friends, did you know that the Azure Web PubSub service
makes it easier for you to deliver
serverless real-time applications?
Now you can publish and subscribe messages using
simple WebSocket connections to build apps such as in-game chat,
live dashboards, and real-time broadcasting.
David Fowler and Liangying Wei are
here to show me how it works today on Azure Friday.
[MUSIC]
>> Hey friends, I'm Scott Hanselman and it's Azure Friday,
I'm here with David Fowler and Liangying Wei,
and we're going to learn today about the Azure Web PubSub service.
PubSub, David Fowler. What is PubSub?
>> Pub Sub is publish-subscribe,
at least that's what it's short for.
If you've ever used Azure signaler or WebSockets or
any bus before to send things between publisher and subscriber,
that's the general notion.
The Azure web PubSub service is about trying to connect
WebSockets on your application on
the server side and handling the skill for you.
It is very much like audio signal if you've seen it,
but instead of using a signal-based client,
you can use any language on server and client
and what [inaudible] as well.
>> When I'm making a web application today,
I use HTTP over port 80 and I say get or post.
It opens up a socket and it talks to something,
and then something comes back,
and then that's the end of it,
and then I just have this chat.
WebSockets are long running, they stay open.
They open and they stay open for a while, is that correct?
>> That's right. The kinds of apps
that are being built are like chat applications,
in-game, games, other things like that.
Th e intent being that you can push from server to client.
See you have this long range handle that's only between server and
client and the server can push data to the client.
>> Let me think if I understand correctly.
If I were going to make a chat application and I'm
Scott Hanselman and I don't know anything about
WebSockets, I'll use HTTP,
my browser can pull and say,
hey, give me more chats,
give me more chats, and I just keep asking,
and that's not really going to scale and the server can't say.
>> Can't push you either.
>> If you have some chats, you can't interrupt me,
I just have to keep asking.
That's when we had pages that would like auto refresh themselves
and that doesn't [inaudible].
>> Instead, you open a connection
from client to server that's long-running,
and you pumped data over that channel in both directions,
either combined to server or server to client.
>> Show me a slide that explains what this looks like.
>> Typically, if you build an application that
once use WebSockets, you would have your clients,
your browsers, your phones, your whatever,
and you have your App Server running
somewhere in Azure, in the Cloud.
You'd open a connection from client to server that's long running.
The hard thing here is you have to manage at scale.
Typically an application,
the requests are stateless
and you make a ton of requests back and forth.
With WebSockets, you have these long-running connections that made
the application stick to your App Server.
It gets tricky to scale this,
as you're handling long-running requests,
and [inaudible] request with the same App Server.
What if there was this magical service
that appeared in the middle?
There's my awesome animation.
>> There we go. You just told me like an hour.
Now my clients can talk to this service,
and I can do HTTP in
between the Azure Web PubSub service and App Server.
Some App Server remains stateless,
it remains HTTP only,
but all the hard WebSocket logic is handled by the service for me.
>> Interesting, all the hard stuff is handled for you.
That's the whole point of the Cloud.
>> It's the whole point.
>> If it's difficult and complicated,
I don't want to do it because I'm just making a chat app,
I'm just making a game.
Why do I have to learn about the ins and
outs of the details of how this works?
>> Right.
>> But there was a thing called SignalR,
signal and a letter R.
>> SignalR.
>> Is this SignalR,
or what's the relationship between
Azure SignalR Service and Azure Web PubSub service?
>> They're very similar,
they're built on the same core fundamental platform.
The main differences are that this is purely serverless,
so the connection between
the web PubSub server and the App Server is HTTP,
and SignalR doesn't see a long-running socket.
From client to server,
you have to use a SignalR client.
The SignalR client is a higher-level protocol that
does RPC on top of any transport,
WebSockets, long pulling, ServerSent events.
It tries to abstract the transport from you,
to hide that from you on the server side.
The Azure PubSub service doesn't try to hide the protocol,
it gives you WebSockets from client to server all the way through.
If you have any platform has of course, WebSockets, you're golden.
>> If I'm a web developer,
I usually just think about HTTP,
I never think about TCP.
If I'm using SignalR,
I would use the SignalR client,
and it hides the ultimate underlying thing.
It might be pulling, it might be whatever.
Azure Web PubSub comes down to that low level and it says,
here's the playground, it's all just WebSockets.
It's a standard and you can use any client, any language.
>> That's right. Under each is it really far.
There is a library for every language,
every platform you can think of.
SignalR doesn't have as many clients.
It could have been, but today we only have support for Java,
JavaScript, and C# in the box.
But before WebSockets, there is a client
for every platform you can think of.
>> Interesting. Well, I like that it's
open and I like that I can do anything with it.
Do we have a demo that we can see?
>> We do have demo.
>> I know that you have that working very hard and I can see her
focusing on making the demo as awesome as it can be.
>> Yeah. Let's switch.
Show us your awesome demos.
>> What do you have here?
>> Let's start with super simple demo,
a chat, a super simple chat.
>> Every single demo, just so you know,
for SignalR or Web PubSub or WebSockets,
it always starts with chat. You always do chat.
>> You can see that it's claims.
Now you joined, and it claims Scott joined.
I'm typing, "Hey,
morning," and you can see that both clients receive this message.
>> When you hit enter right there, it's instant.
It's not like I'm thinking HTTP,
you post, and then you wait,
and then something does a get.
What's happening here, you sent that via HTTP or via WebSockets?
> It's using WebSockets.
Let's see this code,
the super simple webpage that [inaudible] happen.
There are two steps.
The first step is to get the URL,
it needs to connect.
Actually, this URL contains a token needed to
connect two of servers [inaudible] as well
as the URL of our service,
and then it uses this raw WebSocket API directly.
You'll see there's no SDK used here,
it is just a simple WebSocket connection to the service.
Then we'll click this "Enter",
your just to send this message through this WebSocket connection.
>> Then new WebSocket on line 13 there.
A WebSocket is a primitive in JavaScript.
It's available to you, you didn't you
didn't have to bring in a librarian to use that?
>> Yeah, correct, it's native supported in the browser.
>> The web server that served this here,
you're using local host,
that could be an Azure App Service or whatever,
and then that would be the thing responsible for HTTP.
But Azure Web PubSub is responsible for WebSockets.
>> Good question. Our service is responsible
for translate this WebSocket messages to
the App Server using HTTP requests for every message comes in.
>> Wow. This is all the code you had to write.
This is really low-level code,
but it's still not very much code.
>> Yeah. You can see that from this App Server side code,
we have an SDK for the node.js
to help generate this authentication
token for the client to yours.
We have a middleware to,
for the application to handle the incoming events.
You can see that when the client connects,
it has this unconnected callback for
the application to broadcast
messages to all the connected clients,
and for the message sent,
sending to the application.
You can also handle this inside this,
handle using event callback.
>> So then the client is taking care of keeping track of who's
connected and whether if
the message was meant for me or meant for someone else?
>> How does the system know that I'm the publisher?
What if there are one million people in the chat,
and I get a direct message,
do I see all one million chats,
or does it keep track of who I am and making
sure that I only see the specific message meant for me?
>> Yeah, you can Config what events you'll care
about in your application through the service portal.
You can Config the events you care about.
>> Right now you have two users,
you have two browsers.
If you have one million,
become very popular, very famous.
Maybe you're doing halo or some big video game,
how do I scale this?
>> They were perhaps service helps you to handle
these massive concurrent connections.
Your application does not have to worry about that.
You are just to focus on the application logic.
>> That's so cool.
>> You selected the right,
and you pay more money and then you get
more scale. That's how the Cloud works.
>> There's just a slider bar in the display.
>> Yeah.
>> As much money as I have,
this will scale to as big as I want to be.
>> I think the current limit is 100,000 concurrent connections.
There is talk of bumping out further.
>> Okay, but 100,000 per instance or.
>> Per instance.
>> Statistically, if you want Hyperscale,
you can add more instances and they shard that way.
>> Okay, so sharding would be like,
I could go based on an instance,
the way that big giant video games have
I'm in America's instance or in the Asia instance.
>> That's correct.
>> This can scale as big as I could possibly imagine.
>> Yeah.
>> These signals are built on top of these things,
so this is the underlying service that the other services use.
>> They share the same technology,
but they are not dependent on each other.
>> Okay. How do I decide which one that I need?
If I'm making an application today,
how do I know that I want
the Azure Web PubSub service and not the SignalR one?
>> I can answer that. If you're using.net,
just use SignalR because it has all the things both in particular.
If you want a little bit of control and if you're not using.net,
then you want to use Azure pops up.
>> Okay. Is that a fair statement there?
>> Yeah.
>> Okay. If I'm using.net,
then I'm going to have a better experience with the SignalR.
But any other language, anything that we're seeing here,
Node and Express, because we have that line, line 24,
we've got the SDK available that makes it able to be used,
and it doesn't have to be just web applications,
it can be mobile apps or any application. Yes?
>> Yeah, the clients [inaudible].
Any platforms supporting the web is okay.
>> Is this in preview or is this something I can use today?
>> It's in public preview for now.
>> I can use this today.
It's in public preview,
it'll be released sometime soon,
and are there samples and things online where I can learn more?
>> Sure, we have a website that contains
many left demos and
also demos samples that you can try for yourself.
We have left demos that you can try.
Whiteboard, for example.
>> Can I go in there too?
>> Yeah. It's funny.
These demos are always risky to show on
stage or talk because you
don't know what someone is going to type.
>> Okay. Hang on. I'm going to go there right now.
>> Here's a super cool whiteboard demo.
>> That's so cool. Source code is there?
>> Yeah, there are
a couple of cool things about how the antenna works.
If you put the server JS app again,
Scott, there's the client front end.
In JavaScript, there's a back-end and NodeJS,
if you look in the corner there,
just the Ngrok thing running.
To make this work locally,
you need to basically tell
Azure Web PubSub what the backend is that they are going through.
How does it know to send requests to your local host?
We use Ngrok here to expose my local machine as a proxy,
and we configured the Azure portal to say,
whenever you see a message coming in
for the chat application that I have configured,
send an HTTP request to my application.
>> Okay, let me see if I
can say this back to you both and you tell me if
I get it right because Azure Web PubSub is in the Cloud,
it can't send a message back to
local-host and inform you of things.
It has to send something to
a publicly available endpoint, and again,
Ngrok is exposing one of your local ports as
a publicly accessible endpoint
because you chose to open it temporarily.
>> That's right.
>> You've put in temporary basically,
a reverse proxy back to yourself?
>> Yeah. Punching a hole.
>> Punching a hole, yes.
>> Yeah.
>> But only while Ngrok is running locally?
>> Correct. This log shows for that URL,
it shows every request going through it and the format.
We use Cloud events,
which is a new standard that came,
I think two years ago or a year and a half ago.
Pre-pandemic. That describes a webhook in a standard way.
We described the webhook being sent by the address,
the Azure Web PubSub service to your application,
and the SDK unpacks that payload and then causes your application.
>> Right. In Cloud events,
people can learn about that Cloud events dot IO.
It's basically a standard way for event publishers
to describe events in the past that had never been decided upon.
>> Yes. You can send text JSON,
binary, so you can send large files.
You can send content, a bunch of things.
>> I see that she's just started up on load on localhost 8080.
>> Yes.
>> Then Ngrok is forwarding from 4040.
Well, that's the web interface.
>> You can also send,
instead of plain text,
you can also send the JSON object
that's containing much more metadata.
>> You can send any mime types that you want?
Could I even send a picture?
>> You can send a picture/binaries,
we suppose re-tagged, plain texts,
application JSON, and also the binaries.
>> Okay, well, so then
the whiteboard example that you showed there,
we could decide what that payload is.
That's really at the application level to decide the payload,
and you could be sending XY as a JSON payload or whatever.
It's up to you, like when we did this here,
how did we send that information?
>> They seem withdrawal and this is binary
and this is how we type because it
saves texts because for our topic,
it's financial support both binary and text.
>> That's really cool. We also support other clients.
I think one of the main points of this service was to.
>> I just wanted to see if it was possible.
>> That was pretty cool. Go back.
>> Where did it go?
>> Where did it go? They have an openness though.
>> Did you close it? That was me.
>> You scared everyone.
>> That was me. That's me. What do we see here?
>> This is lucky to have a demo, that's pretty cool.
>> Okay.
>> The SDK, it's supposed to much more languages.
Here, actually, this is a feature that we can use inside.
They're actually inside the Azure CLI.
On the folder, Edna goes into a Python SDK
to call the rest API exposed by our service.
You can see that we can use Azure so I had to broadcast messages
to the halfback with Setup hello,
like hallo. Let's see that.
>> Oh wow.
>> Nature the service. Hello. Yeah.
>> That's really good for testing.
>> I had to do. It was even there.
I was like, this is a feature we added.
This is super cool.
>> It is cool. For the Azure CLI,
you have a built-in way to send messages
to any Azure Web PubSub service,
assuming you have permissions to that.
>> But that's what's so cool about this.
Then you can do it for testing.
You can have an Azure function that
can spin up and send something out and
notify people that the system is going
down for maintenance or whatever.
You have full control.
>> Notifications are a pretty common scenario
with this Azure Web PubSub stuff.
>> All right, this is great. I can go and learn out.
I can go and sign up for Azure web PubSub now in preview,
and I can learn all about this today,
and little GA soon.
Where can people leave issues and questions?
Is there a GitHub repository?
>> There's a page, file issues here.
Leave comments, leave suggestions,
send pool requests, I guess.
>> Yeah, all these samples can be our open source.
People can go and read the docs and they
can contribute to the docs as well,
and learn all about this stuff.
>> A ticket, tours a hair for other languages.
Python, JavaScript, c Sharp, Java.
>> All right. Thank you both for your time today.
>> Thanks, Scott.
>> All right. I am learning all about how to build
web socket-based real-time web apps with
Azure Web PubSub today on Azure Friday.
>> Hey, thanks for watching this episode of Azure Friday.
Now, I need you to like it, comment on it,
tell your friends, retweet it,
watch more Azure Friday.
[MUSIC].