Forem: Yan Jin

Protect Your SignalR Service Based Real-time Application with Application Gateway

Yan Jin — Tue, 27 Jul 2021 08:42:38 +0000

By using the Azure Private Endpoint for your Azure SignalR, it allows clients on a virtual network (VNet) to securely access data over a Private Link. As next step, let’s learn how to use the Azure Application Gateway for your Azure SignalR to manage the real-time traffic.

Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web applications. Using the Azure Application Gateway with Azure SignalR Service enables you to:

Protect your applications from common web vulnerabilities.
Get application-level load-balancing for your scalable and highly available applications.
Setup end to end secure.
Customize the domain name.

Let’s go through the key steps together and learn how to implement this reference solution:

The Application Gateway helps you protect your applications and setup end to end secure.
The client cannot access the Azure SignalR Service instance through public network, and all the traffic is managed through Application Gateway.
The traffic between App Service and SignalR Service is also protected by Virtual Network.

Setup the Virtual Network

Create the Virtual Network VN1.
There is a default subnet already created, and add 2 new subnets:
- Subnet applicationSN for your App Service or Azure Functions.
- Subnet gatewaySN for Application Gateway.

Setup SignalR Service

Create the resource of Azure SignalR Service ASRS1.
Go to the ASRS1 in the portal.
Go to the Private endpoint connections blade, and create a new private endpoint PE1 with the VN1 and its default subnet. Learn more details about use private endpoint for Azure SignalR Service.
- Resource
- Resource Type: Microsoft.SignalRService/SignalR
- Resource: ASRS1
- Configuration
- Integration with private DNS zone: Yes
- Subnet: default subnet in VN1
Go to the network access control blade of ASRS1 and disable the all connections in public network.

Setup the Application Gateway

Create the Application Gateway AG1
In the Basic, use the VN1 and gatewaySN to configure the virtual network.
In the Frontends, create a new public address.
In the Backends, create a new backend pool signalr for the SignalR Service resource. You need to use the host name of the SignalR Service resource as the Target.
In the Configuration, add a new routing rule signalrrule to route the traffic to SignalR Service. You need to create a new HTTP setting.
- Listener
- Protocol: HTTP (We use the HTTP frontend protocol on Application Gateway in this blog to simplify the demo and help you get started easier. But in reality, you may need to enable HTTPs and Customer Domain on it with production scenario.)
- Backend targets
- Target type: Backend pool
- Add new HTTP setting
  - Backend protocol: HTTPs
  - Use well known CA certificate: Yes
  - Override with new host name: Yes
  - Host name override: Pick host name from backend target.
Review and create the AG1

Now, we already setup the Virtual Network, SignalR Service and Application Gateway. Let’s quick test whether the configuration is correct.

Go to the network access control blade of ASRS1 and set public network to allow server connection only.
Go to AG1, open health probe, change the health probe path to /api/v1/health
Go to the Overview blade of AG1, and find out the Frontend public IP address
Open http://frontend-public-IP-address, and it should return 403.
Open http://frontend-public-IP-address/api/v1/health, and it should return 200.
Go back to the network access control blade of ASRS1 and disable the server connection in public network.

Run a Chat Application Locally

Now, the traffic to Azure SignalR is already managed by the Application gateway. The customer could only use the public IP address or custom domain name to access the resource. In this blog, let’s use the chat application as an example, and start from running it locally.

Clone the github repo https://github.com/aspnet/AzureSignalR-samples
Go to the Keys blade of ASRS1 and get the connection string
Go to samples/Chatroom and open the shell
Set the connection string and run the application locally

dotnet restore 
dotnet user-secrets set Azure:SignalR:ConnectionString "<connection-string-of-ASR1>;ClientEndpoint=http://< frontend-public-IP-address-of-AG1>" 
dotnet run

Open http://localhost:5000 and view network traces via explorer to see WebSocket connection is established through AG1

Deploy the Chat Application to Azure

Create a Web App WA1.
- Publish: Code
- Runtime stack: .NET Core 3.1
- Operation System: Windows
Go to Networking blade and configure the VNET integration.
Select VN1 and webapp subnet applicationSN
Publish the Web App with CLI
- Publishe the application and its dependencies to a folder for deployment

dotnet publish -c Release

Package the bin\Release\netcoreapp3.1\publish folder as app.zip.
Perform deployment using the kudu zip push deployment.

az login  
az account set –subscription <your-subscription-name-used-to-create-WA1> 
az webapp deployment source config-zip -n WA1 -g <resource-group-of-WA1> --src app.zip

Go to the Configuration blade of WA1, and add following application setting to set connection string and enable private DNS zone.

Azure__SignalR__ConnectionString=<connection-string-of-ASR1>;ClientEndpoint=http://< frontend-public-IP-address-of-AG1> 
WEBSITE_DNS_SERVER=168.63.129.16 
WEBSITE_VNET_ROUTE_ALL=1

Go to the TLS/SSL settings blade of WA1, and turn off the HTTPS Only. To Simplify the demo, we used the HTTP frontend protocol on Application Gateway. Therefore, we need to turn off this option to avoid changing the HTTP URL to HTTPs automatically.
Go to the Overview blade and get the URL of WA1.
Open the URL by replacing the https with http, and open network traces to see WebSocket connection is established through AG1.

Next Steps

Now, you are successful to build a real-time chatroom application with Azure SignalR Service and use Application Gateway to protect your applications and setup end to end secure.

If you are trying to build your own application with Azure SignalR and Application Gateway, you could also get more helpful resources from the Azure SignalR Service and Azure Application Gateway. We are looking forward your feedback and ideas to help us become better via Azure Feedback Forum! You could also go to Tech Community to learn more blogs about Azure SignalR Service.

Build a real-time whiteboard application with Azure Web PubSub

Yan Jin — Wed, 07 Jul 2021 09:22:28 +0000

The COVID-19 pandemic has led to unprecedented measures and is also changing the way we work. In addition to restricting travel and canceling large events, a growing number of companies are encouraging to work remotely. In order to continue working efficiently and creating value under these new circumstances, organizations need to adopt different applications with different scenarios, e.g., web conference, remote collaboration, etc. The real-time whiteboard is one of the tools to help you build remote collaboration and bring your teams together, anytime, anywhere, e.g., running productive and engaging online meetings and workshops, building and developing ideas with distributed teams, explaining complex process and system with visual map or diagram, etc. The Azure Web PubSub (AWPS) which is a fully managed service could help you build the real-time whiteboard application. Let’s learn how to build a whiteboard demo together.

What’s the whiteboard demo?

This whiteboard demo demonstrates how to build a web application for real time collaboration using Azure and other related technologies. The fundamental feature of this application is allowing anyone painting on it and synchronizing the paint to others in real-time. The user could paint with the basic paint tool, touching on mobile devices or uploading images.

Before we start digging into details, you can first play with this demo online. Open this site and input your username, then draw anything you like in the whiteboard. Open another browser window you'll see your changes are synchronized in real-time.

You can also find the source code of this demo here.

Synchronize real-time data between client applications

One of the key features in this whiteboard is its ability to synchronize the drawing between multiple client apps in real-time. This is implemented by using WebSocket technology, which is commonly used in web applications for bidirectional communication. If you're already familiar with WebSocket and look into the implementation in server.js, you'll notice it's very different than a typical WebSocket server. In a typical WebSocket application, server needs to manage all client connections and handle data transfer between clients. So you can imagine in a whiteboard app, server will receive the drawing from one client and broadcast it to all other clients, which will generate huge traffic when everyone is drawing and processing all those data will be a big burden to the server.

If you look at our whiteboard server, you'll see it's a standard express.js server application (we don't go through details about how to use express.js here, you can refer to its official docs to learn more). Instead of having code to handle WebSocket connections, it creates a WebPubSubEventHandler and use it as a middleware in the express app.

let handler = new WebPubSubEventHandler(hubName, ['*'], {
  path: '/eventhandler',
  handleConnect: ...
  onConnected: ...
  onDisconnected: ...
  handleUserEvent: ...
});
app.use(handler.getMiddleware());

By using this Web PubSub event handler, we're leveraging Azure Web PubSub service to manage the client connections for us.

In the event handler there're some callbacks like onConnected and onDisconnected, which are similar to open and close events in WebSocket, but the key difference here is when using Azure Web PubSub service, the connection is connected to the service, your server just gets a notification when this happens but does not need to manage the lifetime of the connection. This is usually challenging in real scenarios where you need to handle things like connection routing and load balancing. In Azure Web PubSub they're all taken care of by the service.

Also in the server code you'll notice there is no code to pass the data from one client to another, this is purely done at client side. Look at the client you'll see code like this:

this._webSocket.send(JSON.stringify({
  type: 'sendToGroup',
  group: group,
  dataType: 'json',
  data: data
}));

This code sends a message to the WebSocket connection but there is no code at server side to handle it! This is because it is processed at service side. Azure Web PubSub can understand message from client (in this case it's asking service to send this message to a group) and send the message to the corresponding clients (which is called publish/subscribe pattern). So you can see by using Azure Web PubSub you can save a lot of server resources (like CPU and network bandwidth) by offloading WebSocket connections to the service.

Maintain state at server side

Even Azure Web PubSub helps us deliver real-time updates between clients, client still needs to send drawing data to server so it can be saved at server side. So next time when a new user opens the whiteboard, they can see all paintings others draw before.

This is done by sending an event from client to server. Event is another communication pattern (comparing to publish/subscribe pattern we use for sending real-time updates) in Azure Web PubSub for clients to send data to server.

In client, there is code like this:

this._webSocket.send(JSON.stringify({
  type: 'event',
  event: 'message',
  dataType: 'json',
  data: data
}));

This code sends an event to server and there is corresponding server code to handle it:

let handler = new WebPubSubEventHandler(hubName, ['*'], {
  path: '/eventhandler',
  ...
  handleUserEvent: async (req, res) => {
    let message = req.data;
    switch (message.name) {
      case 'addShape': ...
      case 'removeShape': ...
      case 'clear': ...
    }
    res.success();
  }
});

You can see the code above handles three types of events (when user adds a new shape, removes an existing shape or clears the whiteboard) and save the data to a local diagram object (for demo purpose, in a real application you should use a persistent storage to store this diagram).

You can see there is still data communication between client and server, but comparing to the real-time updates between clients (which happens whenever a user moves their mouse on the screen), this only happens when a user finishes drawing a shape, so the amount of data is much less than the real-time updates.

Besides user events, Azure Web PubSub also supports some system events like connected and disconnected so server can know the status of client connections. You can see in the server code, they're used to track the total number of clients online.

Use WebSocket API in client

Azure Web PubSub uses WebSocket API for its client programming interface. As long as your programming language supports WebSocket, you don't need to install any third-party library. You already see how to send messages through WebSocket in previous sections, but there are a few more things you need to be aware before using it:

Authenticate with service

Azure Web PubSub doesn't support anonymous connection, so in order to connect to the service each client needs to authenticate with it using a JWT token. Azure Web PubSub SDK already provides an API to generate the token from connection string. A recommended implementation is to expose a Web API (usually called negotiate) at server to return this token (the API itself can be protected by your own authentication mechanism). In the demo app it's implemented like this:

app.get('/negotiate', async (req, res) => {
  let token = await serviceClient.getAuthenticationToken({
    roles: ['webpubsub.sendToGroup.draw']
  });
  res.json({
    url: token.url
  });
})

In the negotiate you can also control the permission of client (like which group it can send message to).

Create connection

Create connection is really simple but you need to specify a subprotocol if you want to directly send messages between clients.

let res = await fetch('/negotiate');
let url = res.json().url;
let ws = new WebSocket(url, 'json.webpubsub.azure.v1');

With json.webpubsub.azure.v1 subprotocol, you'll be able to join, leave and publish messages from client (more details can be found here).

If you don't specify subprotocol you can still connect, but all messages you send will be treated as events and be sent to server.

Handle reconnect

It's very common that WebSocket connection will drop due to things like network glitches, long time inactivity at client side, etc. So to improve the stability of the client app you should always consider reconnect when it disconnects.

In Javascript if a WebSocket connection is closed you need to create a new WebSocket object to reconnect, which means for all callbacks you registered on the old object you need to re-register in the new one. In this demo we created a simple WebSocketClient class to wrap the raw WebSocket object so it will automatically reconnect and re-register all callbacks. Check out the source code to see how it works.

Next Steps

Now, we already go through the key points to build the real-time whiteboard application with Azure Web PubSub service. If you are looking for more details about this demo, you can refer to the whiteboard application on Github where the code is hosted, along with information and docs on how to deploy and run it yourself.

If you are trying to build your first real-time application with Azure Web PubSub, you could also get more helpful resources from the getting stared contents. We are looking forward your feedback and ideas to help us become better via Azure Feedback Forum!

More Information

This blog is also posted on Tech Community and you could also get more blogs about the Web PubSub and its new features here.

At last, thanks for Ken Chen offering the demo and technical details.

Build serverless real-time chat application with Web PubSub and Static Web Apps

Yan Jin — Tue, 22 Jun 2021 02:53:52 +0000

With the growth of internet and mobile, building the cross platform real-time chat experience into your application also becomes a very common need, for example patient and doctor chat in healthcare, customer support chat in eCommerce, student and teacher chat in remote education, players chat in eGaming, instant chat for social media or live video stream, and so on. The real-time chat experience offers several values to your application to help your customers success:

Instant and efficient communication to faster problem resolution.
Collaboration and purposeful conversation to overcome business challenges.
Smooth built-in experience to improve the customer service and loyalty.
Cross platform support to empower the customer to discovery easily.

In general, there are some fundamental and critical needs for an application with build-in real-time chat experience:

Real-time chat experience with users.
Management of user and group.
Notification and popup.
AI-enabled, e.g., language moderator, bot, etc.
Typing indicator.

But it is not easy to build these functionalities into your application from scratch. You may have the issues to achieve the real-time performance, handles hosting, scalability, load balancing and other infrastructure related challenges, adapt with multiple client platforms, etc. Now, the Azure Web PubSub service which is a fully managed service give the opportunity to you to enable the real-time capability to your application with native and serverless WebSockets support.

Let’s follow with Ben Coleman together to build a serverless Chatr web application and learn how does he leverage the advantages of the Azure Web PubSub and Azure Static Web Apps to achieve this easily and quickly.

What's the Chatr?

Chatr is a simple real-time, multi-user chat application, highlighting the ease of building applications on top of two of Azure services: Azure Web PubSub and Azure Static Web Apps. The Chatr application provides many of the features you might expect; a way to sign in and authenticate, group chats, user to user private chats, a global online user list, idle (away from keyboard) detection and more. However it was built to be a way to learn and showcase possibilities rather than a fully fledged and production grade chat system.

Chatr consists of four components:

The client or frontend, which users interact with – This is written in JavaScript and uses Vue.js
The backend service, which provides message processing & event handling, written in Node.js
A globally available but secure Websockets service – provided by Azure Web PubSub
Persistence state storage and key value store – provided by Azure Table Storage

A diagram will help illustrate how these all interact, and some of the main message & data flows. Let’s explore these components in more detail.

Use Web PubSub to build the scalable backend

The Azure WebPubSub service works hand in hand with the Chatr backend, to provide the core chat functionality. This is done through ‘event handlers’ within Azure WebPub sub, these handlers enable an upstream service to receive client side WebSocket messages as “events”. These events are HTTP messages, which the service can then react to. These events supports both a range of built-in system events (e.g. client connecting or disconnecting) but also custom application specific events, in the case of Chatr there are many of these such events, for example “joinChat” or “userEnterIdle” etc.

The backend uses the service client of the Web PubSub SDK for Node.js, which can be instantiated easily. Here we are storing configuration details such as the connection string in an Azure Function App Settings, and obtain it them securely through environmental variables.

const { WebPubSubServiceClient } = require('@azure/web-pubsub')
const CONN_STR = process.env.PUBSUB_CONNECTION_STRING 
const HUB = process.env.PUBSUB_HUB 
const serviceClient = new WebPubSubServiceClient(CONN_STR, HUB)

Within the Function itself we can handle any event sent to us from clients by binding to HTTP trigger POST requests and processing them as follows. For example, the code below shows how Chatr handles when a user has created a new shared group-chat. When doing so they send an event called “createChat”, when handling this we get the properties we require from both the headers and the HTTP body, (the special 'ce' headers are populated by Azure Web PubSub), then store into state and finally notify all clients about the new chat with an outbound message.

const eventName = req.headers['ce-eventname'] 
const userId = req.headers['ce-userid'] 

if (eventName === 'createChat') { 
  // Build custom event payload 
    const chatPayload = {  
    id: req.body.id,  
    name: req.body.name,  
    owner: userId  
    } 

  // ... Update state, removed for brevity ... 

  // Send message to all clients with custom JSON payload 
  // Will be routed via Azure Web PubSub with WebSocket protocol 
  serviceClient.sendToAll({ 
    chatEvent: 'chatCreated', 
    data: JSON.stringify(chatPayload),
  }) 
}

Build frontend with extensive platform and host easily with Static Web Apps

The Chatr frontend consists of a JavaScript static app or SPA (single page application) built on the Vue.js framework, this is hosted using the Azure Static Web App service as a set of HTML and JS files. This Azure service aside from just hosting static content, also provides Chatr a means to sign in and authenticate users and also a way to host the backend Azure Function service. The frontend establishes a secure connection to Azure Web PubSub using WebSockets, no SDK or client libraries are required making it quick easy to use. Let's walk through the frontend together.

Setup connection between application and backend service

The clients first request a way to access to Azure Web PubSub by calling a REST endpoint on our backend which in turn obtains a client access URL (which includes an access token) this is done using the same serviceClient described above, as this is done server side it provides a way to restrict access and secure the application. In the case of Chatr all users are permitted to request an access URL. The userId in the code below has been fetched previously through a call to Azure Static WebApps, for the purposes of Azure Web PubSub. It’s simply a string and has no special meaning.

// Get URL & token to connect to Azure Web Pubsub 
res = await fetch(`/api/getToken?userId=${userId}`) 
let token = await res.json() 

// Now connect to Azure Web PubSub using the URL we obtained 
let ws = new WebSocket(token.url, 'json.webpubsub.azure.v1')

We only use standard modern JavaScript APIs like fetch and WebSocket this means the Chatr frontend can be deployed without any bundling or WebPack stage. Also note how we use the ‘json.webpubsub.azure.v1' subprotocol when establishing the connection, this extension to plain WebSockets provides a range of additional capabilities which are used by Chatr such as; client to client messaging (without a round trip to the server), a means to join send messages to groups (which is how Chatr provides group chats) and also a way to send custom events which are routed to the service as described above.

Send custom event or message

Sending a custom event from the client is very simple, for example.

ws.send(
  JSON.stringify({
    type: "event",
    event: "createChat",
    dataType: "json",
    data: { name: chatName, id: chatId },
  })
);

Chat messages between users are sent a very similar way, except leveraging the 'sendToGroup' message type. Rather than plain text strings (which are also supported) we enrich the messages we send with meta data such as the userId of who sent the message and send a JSON payload. It’s important to note these messages are not relayed by the Chatr backend we described above, they are handled entirely by the Azure Web PubSub service without any backend or server code.

ws.send(
  JSON.stringify({
    type: "sendToGroup",
    group: chatId,
    dataType: "json",
    data: {
      message: message,
      fromUserId: userId,
    },
  })
);

Summary

We’ve just scratched the surface of what the Chatr sample app does, and we’ve not covered details such as how state is stored using Azure Tables or how the authentication wrappers of Azure Static WebApps are used. However I hope what we have shown illustrates some of the power and flexibility of Azure Web PubSub. If you are looking for more details about this application, you can refer to the Chatr repo on GitHub where the code is hosted, along with information and docs on how to deploy it to Azure and run it yourself.

Next Steps

If you are trying to build your first real-time application with Azure Web PubSub, you could also get more helpful resources from the getting stated contents. We are looking forward your feedback and ideas to help us become better via Azure Feedback Forum!

More Information

This blog is also posted on Tech Community and you could also get more blogs about the Web PubSub and its new features here.