DEV Community: Kevin Guo

Socket.IO user study

Kevin Guo — Mon, 28 Aug 2023 03:26:32 +0000

Hello Socket.IO and real-time app developers,

Since we put up an invitation to participate in a user study, we collected hundreds of responses and had the chance to speak in depth with several Socket.IO users. Thank you for your interest in the user study and for helping us understand your experience.

In this post, I am going to share with you some notable learnings from the study. It’s our hope that such sharing can shed light on how we can build a stronger community as Socket.IO users, contributors, and cloud providers.

Socket.IO is used in a wide range of app scenarios.

We were pleasantly surprised by the variety of applications built using Socket.IO. Although a fair number of users reported building chat apps using Socket.IO, many shared that they use Socket.IO for identity management to limit the number of active browser tabs, for robotics to control the movement of mobile robots, for multi-player mobile games and for collaborative apps where users can track work items in real-time.

Overwhelmingly, users enjoy the “intuitive APIs”.

Users seem to have exhausted the synonyms for “intuitive” in their responses. Once users have gone over the initial learning curve, it doesn’t take long before they can get productive with Socket.IO’s APIs, which are described as “simple”, “easy” and “plain”. Plains APIs are definitely a praise in this case.

Some users seem to have doubts about Socket.IO’s viability for large projects.

Users new to Socket.IO seem to have the impression that Socket.IO is for small-scale and toy projects and it would be necessary to find alternatives when an app needs to scale. I am happy to report that the impression doesn’t reflect the reality; a few Socket.IO users shared that their apps handled 10s of thousands of concurrent connections well, powered by running multiple Socket.IO instances behind a load balancer.

Scaling out a Socket.IO is where developers report the most pain.

Scaling out a Socket.IO app requires a multi-server setup. Essentially, client connections are spread across several Socket.IO server instances. To emit an event to clients connected with different server instances, there needs to be a component to coordinate the message passing. While simple in broad-stroke description, implementation is not particularly straightforward or familiar to most users. Deploying and maintaining a separate adapter component adds additional complexity to the task.

This is an area where we studied the most and thought we could bring the most value to developers. I am happy to share with you that with the input from the open-source community, we brought support for Socket.IO on Azure. With this support, Azure hosts and manages client connections; in other words, developers don’t need an “adapter” component.

What’s more important is that server and client apps continue using the same and familiar Socket.IO APIs. With only a few lines of code, you can get any socket.io apps running locally to Azure. You can learn more about the support and try it out for free by following the links below.

Resources

Overview of Socket.IO support on Azure
Quickstarts of hosting a Socket.IO app on Azure

Socket.IO on Azure

Kevin Guo — Thu, 24 Aug 2023 03:36:09 +0000

Socket.IO powers a variety of real-time applications.

We have been conducting user studies with Socket.IO users for the past few months and had the chance to meet the core maintainer of the open-source project. We were pleasantly surprised by the variety of applications built using Socket.IO, from identity management to robotics, not just chat apps.

Scaling out Socket.IO apps can be frustrating for developers.

Overwhelmingly, users reported their love of the “intuitive APIs” and how easy it is to get productive with the library once they get over the initial learning curve. However, scaling out a Socket.IO app is where the most frustration and difficulty lie. Developers would much rather focus on building real-time experiences than developing and maintaining an “adapter” component like Redis.

Host Soket.IO app on Azure for simplified architecture, scalability, and 99.9%+ uptime.

With input from the open-source community, we brought support for Socket.IO on Azure. Socket.IO developers can continue using the familiar APIs they come to love from Socket.IO and let Azure handle scalability and availability. This means developers no longer need an “adapter” component. The Socket.IO server communicates with an Azure service and the Azure service fans out messages. The app architecture is simplified and more robust. See the diagram below. To see the full benefits of an Azure-managed Socket.IO app over a self-host approach, read this article.

Hosting a Socket.IO app to Azure takes only a few lines of code.

Getting a Socket.IO app running locally to Azure requires only a few lines of code change. The following sections will walk you through how to host a simple chat app built with Socket.IO on Azure.

What you need

To follow the steps, you will need

An Azure account with an active subscription. If you don’t have one, you can create a free account.
Some familiarity with the Socket.IO library.

Create a Socket.IO resource on Azure portal

Head over to Azure portal and search for “socket.io”.

Note that the support for Socket.IO is provided through an Azure service called Web PubSub.

Create a Node project and install the required packages

Note that beyond “socket.io-client” package, we also need “@azure/web-pubsub-socket.io”.

mkdir chatapp
cd chatapp
npm init
npm install @azure/web-pubsub-socket.io socket.io-client

Write server-side code

/* server.js */
// Import required packages
const { Server } = require("socket.io");
const { useAzureSocketIO } = require("@azure/web-pubsub-socket.io");

// Configure connection with the Azure service
const wpsOptions = {
    hub: "eio_hub", // The hub name can be any valid string.
    connectionString: process.argv[2] || process.env.WebPubSubConnectionString
}

// Create a Socket.IO server supported by Azure
let io = new Server(3000);
useAzureSocketIO(io, wpsOptions);

// Write message passing logic using Socket.IO's APIs.
// This code snippet is taken from Socket.IO's website and should be familiar to Socket.IO users.
io.on("connection", (socket) => {
    // Send a message to the client
    socket.emit("hello", "world");

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

Write client-side code

/* client.js */
const io = require("socket.io-client");

const webPubSubEndpoint = process.argv[2] || "<web-pubsub-socketio-endpoint>";
const socket = io(webPubSubEndpoint, {
    path: "/clients/socketio/hubs/eio_hub",
});

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

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

Run the app

// Run server
node server.js "<web-pubsub-connection-string>"

// Run client
node client.js "<web-pubsub-endpoint>"

Additional resources

Overview of Web PubSub for Socket.IO
How to migrate a self-hosted Socket.IO to be fully managed on Azure

What is WebSocket? (Part 2/2)

Kevin Guo — Mon, 28 Nov 2022 02:19:49 +0000

Summary

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

Definition

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

Full-duplex

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.

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.)

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.

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

🔗 A simple chat app
🔗 A collaborative whiteboard app

Credits:

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

What is WebSocket? (Part 1/2)

Kevin Guo — Mon, 14 Nov 2022 07:25:13 +0000

Summary

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

Quick links

Explore a few live apps built with Web PubSub, a fully managed WebSocket service from Azure.
A simple chat app
A collaborative whiteboard app

Definition
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).

Bidirectional

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.

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 www.nytimes.com, 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.

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.

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

Credits:
GitHub@JialinXin Thank you for reviewing the article.
The bicycle photograph is taken by Philipp M.
The bi-fold door photograph is taken by sena.