Build real-time communication applications with Azure Web PubSub

If there’s one lesson we’ve learned from a rapid shift to remote working, it’s that collaboration relies on real-time connections between applications. If you’re sharing a document with a colleague, you want to be able to see what they’re working on and when. In education, shared whiteboards allow teachers to encourage students to show what they have learned, while curated co-browsing sessions help bring back the one-on-one nature of shopping in a small store.

Microsoft recently released a set of Azure tools, Azure Web PubSub, to help build and run this new generation of applications, taking advantage of the Azure platform-as-a-service approach and its serverless tools to host a publish-and-subscribe service designed to mix one-to-one, one-to-many, and many-to-many communications, all while taking advantage of cloud economics and scalability to deliver a relatively low-cost service.

Introducing Azure Web PubSub

At the heart of the Azure Web PubSub platform is the WebSockets protocol. Supported by all the major browsers and by most code platforms, WebSockets offer a two-way connection between a server and an endpoint, with support for full duplex communications. Both endpoint and server can send and receive data at the same time, allowing a real-time conversation between applications (and users). It’s an important design pattern, as it provides the scaffolding for all types of applications from chat to screen sharing, from document collaboration to gaming, and from real-time Internet of Things sensing to live telemetry feeds.

WebSockets isn’t best suited for video and audio (though they are supported); for that you should be thinking about WebRTC and similar protocols. With WebSockets you’re sharing text-based information. That might be updates to a JSON document or a stream of financial data or both sides of a chat. It’s a surprisingly useful technique, as much of what we want to do in real time isn’t limited to voice and video and doesn’t need to rely on high-bandwidth connections.

Like much of Azure’s application and messaging platform, Azure Web PubSub is a managed service. You don’t need to stand up a server; that’s all handled by Azure. It manages scaling and reliability for you, so all you need to work on is your code. The scaling aspect of Azure Web PubSub is probably its most important feature. It’s designed to work at scale, using globally replicated instances to support millions of connections.

Azure Web PubSub is a classic publish-and-subscribe architecture, with the hubs treated as the publisher and clients as subscribers. This simplifies control flows and ensures that your application always remains in control of messaging. Clients connect via WebSockets, with libraries available for most languages and platforms, and initial documentation for JavaScript, C#, Python, and Java.

Building Web PubSub applications

Working with Azure Web PubSub is much like using any other Azure platform service. You start by creating a service instance from the Azure Portal and adding it to a resource group. Then it creates a client access URL which is stored in the portal. This contains an access token that verifies clients against your service.

Once you have the Azure service enabled, you can build a client using any standard WebSocket library. As it’s an open standard, many different libraries can be used, with implementations for most common languages and frameworks. Microsoft has released its own Python library, with full support for Azure authentication and endpoints. There’s also a .NET library currently under development.

It’s an easy library to use. Start by creating a WebPubSubServiceClient class to hold endpoints and authentication secrets. Once you have created the class, you can use it to construct messages and send requests to your Azure-hosted hub. If you’re not using a library, Microsoft has documented a set of REST APIs for the service, so you can quickly build and use your own code.

Looking at the Azure Web PubSub service from the client side, there are a handful of key concepts. The first is the hub, which controls all the connections for a specific set of clients, with messages sent as either JSON, UTF-8 strings, or binary data. Users can have multiple connections to the hub, while groups manage the rebroadcast of messages into and out of a hub. Each connection has its own unique ID to route and manage messages. A message sent from a hub to a specific connection will only be delivered to that connection.

Everything is a client

On the Azure side, Web PubSub can connect to any code running on Azure. Again, use the connection string to connect your code to your hub. It’s perhaps best to think of your server code as just another client, albeit with tools to support client authentication and manage events sent from clients. A server application can be treated as a specific connection (or if you’re scaling with multiple hubs, as a specific user), so that any messages sent from a client to a server via Web PubSub are routed directly to the server and not to other clients, keeping them private.

This model works well with serverless code, for example using Azure Functions for your server, with separate functions to handle authentication and processing messages. Each message is an event, and so triggering a new Function instance with each message or using a tool like Event Grid along with Cloud Events to add message queuing will allow a Web PubSub application to quickly scale.

The service uses a hub-and-spoke model to manage connections. When you create a Standard instance, you’ll be asked to set a unit count. Each unit is a hub that can accept up to 1,000 client connections, with a maximum of 100 units. If you’re developing a service, you can choose a Free tier, which gives you a single 20-connection unit and as many as 20,000 messages a day, which should be enough for most test and development needs. The full Standard tier has unlimited messaging, with preview prices of $1.61 per unit per day and $1 per million messages (with the first million free). As with most Azure Preview services, you should expect pricing to change when it goes into general availability.

If you’re building tools that need a real-time component and you want something that’s more widely supported than .NET’s SignalR, Azure Web PubSub is well worth a look. Building on common web protocols and using relatively simple message payloads, it’s a useful tool for adding a wide range of messaging and event routing to web applications. With a million messages costing about a dollar, it’s a tool that should scale well without hurting your budget.