Skip to main content

· 4 min read
Kevin Guo


Socket.IO library is natively supported on Azure.

Since we public previewed this feature, we received positive feedback from users. Now we are happy to share that Web PubSub for Socket.IO is generally available, which means that Azure customers can expect stable APIs, SLAs customer support and it’s suitable for use in production.

🔗 Follow this quickstarts guide to try out the feature.

🔗 Check out the repo of a collaborative whiteboard app that showcases the use of Socket.IO APIs and how Azure handles scalability challenges.

Solve scalability issue without code rewrite

When we interviewed Socket.IO users, the challenge of scaling out Socket.IO servers came up repeatedly. It’s a challenge that can be met uniquely by Azure. With the input from Socket.IO users, it’s a challenge we aimed to solve when we public previewed the support for Socket.IO on Azure two months ago.

Developers can continue using the Socket.IO APIs they know and love and migrate to Azure seamless without code rewrite. The following shows what’s needed in the server-side and the client-side code to get a Socket.IO app running on Azure and instantly reap the benefits of Azure’s massive scale (million+ concurrent users).

Introduce additional benefits to enterprise-level applications

Web PubSub for Socket.IO aims to address the scalability challenge Socket.IO developers face. Additionally, it offers enterprise-focused features.

  • Cross-region replication to make your application more resilient by running in independent Azure regions
  • Custom domain to add an extra layer of security
  • Auto-scaling to dynamically scale up and down based on usage

An example showing how easy it is to migrate a Socket.IO app to Azure

Server-side code

Developers only need to call useAzureSocketIO() to set up the communication between this server and the cloud service. To Socket.IO users, the rest of the code should familiar as they are the APIs of Socket.IO library. These lines are included here for completeness of a working program.

const { Server } = require("");
const { useAzureSocketIO } = require("@azure/");

let io = new Server(3000);

// Use the following line to integrate with Web PubSub for Socket.IO
useAzureSocketIO(io, {
hub: "Hub", // The hub name can be any valid string.
connectionString: "<connection-string>"

io.on("connection", (socket) => {
// Sends a message to the client
socket.emit("hello", "world");

// Receives a message from the client
socket.on("howdy", (arg) => {
console.log(arg); // Prints "stranger"

Client-side code

The change to the client-side code is also minimal. Notice that we are using package and when initializing socket object, we set it up so that the Socket.IO client connects with the cloud service. The rest of the code is included for completeness of a working program.

const io = require("");

const socket = io("<web-pubsub-socketio-endpoint>", {
path: "/clients/socketio/hubs/Hub",

// Receives a message from the server
socket.on("hello", (arg) => {

// Sends a message to the server
socket.emit("howdy", "stranger")

How does it work?

As you can see from the code snippets, both the Socket.IO client and Socket.IO server establish a connection with a cloud service. The benefit of having a cloud service to facilitate the communication between the two is that it reduces the load on your Socket.IO server and removes to the need to worry about what if “I need to send messages to 1000+ clients”. All that’s required is the same `socket.emit()`` call. The cloud service, which maintains persistent connections with your Socket.IO clients, fans out the message to all the clients. Graphically, it looks like this.

Architecture of Socket.IO managed by Azure

You can read more about how it works behind the scenes 🔗 by reading the article.

Now generally available.

Since public preview, we received positive feedback from developers and now we are happy to share that this feature is generally available and suitable for use in production. Besides stable APIs and SLA guarantees, developers can have full support through Azure’s ticket system.

Resources and references

· 3 min read
Jialin Xin
Kevin Guo


This article is the second of a two-part series that describes the values of WebSocket on a high-level.

Explore a few live apps built with 🔗 Web PubSub, a fully managed WebSocket service from Azure.

🔗 A simple chat app
🔗 A collaborative whiteboard app


WebSocket gives developers a bidirectional, full-duplex communication channels over HTTP through a single TCP connection


To put it simply, “full-duplex” means that data can be transmitted at the same time in both directions. Like “bidirectional” we just talked about, full-duplex is also about two things, two entities, but full-duplex is more about the TIMING of sending data.

A phone call is considered full-duplex because both the caller and the receiver can send voice data to each other at the same time.

A walkie-talkie is considered half-duplex because at one time only one person can send voice data. The participants take turns to speak.

Picture of a walkie-talkie

The web before WebSocket was largely half-duplex. The client opens a communication channel and requests a resource through this channel from a remote server. It waits for the server to return the requested resource. While the client waits, it cannot send data through the same channel. Also, while the server is sending data, the client cannot request resource through the same channel, much like how we communicate with a walkie-talkie.

Imagine if you are talking with your grandma using a walkie-talkie and you ask “Grandma, what’s like when you were growing up in the countryside?” Grandma presses the “Talk button” and she starts from the Great Depression, World War 1 and on with World War 2… While grandma paints the scene of her storied life, teasing grandma by completing the stories for her is not an option. Your only option? Listen on. (No grandmas were hurt in telling this joke.)

Picture of a grandma and her granddaughter

The walkie-talkie style of the early web was fine when communication was largely infrequent requests for resources from client to server. For web applications with interactive experience, like a collaborative document or a collaborative design application, users could be making changes at the same time and to have a smooth real-time editing experience, the changes need to be reflected on users’ screens as soon as they are made. The trusty HTTP protocol, being an inherently half-duplex communication model, cannot meet the new requirements without resorting to some workarounds. Hacks no more! WebSocket brings native full-duplex communication to the web.

To conclude

“Bidirectional” and “full-duplex” are the two value propositions WebSocket offers to developers and it has enabled a myriad of new interesting experience on the web, multi-player gaming, online auction, real-time collaborative apps and online chatting, to name a few. And the best of it all, it does not take much to add these real-time capabilities to your applications. Some scenarios that can be enabled by WebSocket

The walkie-talkie and the grandma photographs were taken by 🔗 cottonbro studio.

· 3 min read
Jialin Xin
Kevin Guo


This article is the first of a two-part series that describes the values of WebSocket on a high-level.

Explore a few live apps built with 🔗 Web PubSub, a fully managed WebSocket service from Azure.

🔗 A simple chat app
🔗 A collaborative whiteboard app


WebSocket gives developers a bidirectional, full-duplex communication channels over HTTP through a single TCP connection

Let us unpack this loaded sentence together and try to understand the italicized words (technical jargon).


The prefix “bi-“ means two of something. We have bicycles, two wheels. We have bifold doors, the fancy doors with two folds. In the context of computer networking, no surprise here, bidirectional means two directions.

Picture of a bicycle, bi-fold doors and bi-directional communication in computer networking

However, to truly understand the significance of it, we will need to talk about the interaction between applications running on different computers on a network.  In a typical client and server model, the client sends an HTTP request. Once the server receives the request, it does some processing and returns an HTTP response. Most of the activities on the web can be simplified to this request and response interaction. For example, when we visit, the browser sends an HTTP request on the user’s behalf and waits for an HTTP response from its server.

What is relevant to our discussion here is that the client ALWAYS initiates the communication, in other words, the client always asks before the server responds. We can call this form of communication one-directional because the server cannot send data to clients that is not requested. This is the decision made by the designer of HTTP protocol, and this simple design is the technological backbone of the internet.

Client makes request and server responds.

As the web welcomes more and more users, they are increasingly demanding more dynamic and interactive web experience. They want to track their ridesharing car without closing and reopening the app; they want to see the latest financial data, bid in an auction, collaborate on a document all without refreshing the browser all the time. A one-directional communication becomes inadequate in these scenarios. To enable these experiences, the web needs a way for server to send data to clients without client asking. Until WebSocket was standardized in 2008 and quickly supported by modern browsers, the web was unapologetically one-directional. With a bit of uneasiness and feeling cheating, software developers came up with workarounds to mimic bidirectional communication. Hacks no more! WebSocket brings native bi-directional communication to the web.

WebSocket enables bi-directional communication

In the second part, we will explore the idea of “full-duplex”.

The bicycle photograph is taken by 🔗 Philipp M.
The bi-fold door photograph is taken by 🔗 sena.

· One min read
Wanpeng Li

This is a site dedicated to showing developers what they can build with Azure Web PubSub through live demos. If a picture is worth a thousand words, a live demo is probably worth a lot more than that.

Azure Web PubSub is a cloud service that helps you build real-time messaging web applications using WebSockets and the publish-subscribe pattern easily. This real-time functionality allows publishing content updates between server and connected clients (for example a single page web application or mobile application). The clients do not need to poll the latest updates, or submit new HTTP requests for updates.

Check out the demos on the site and let us know what you think.