Preet Taparia

Posted on May 12

What is WebSocket and When to Use Them

#websockets #webdev #learning #programming

Have you ever wondered how collaborative tools like Google Docs update in real-time or how chat applications deliver messages instantly? Behind these seamless experiences lies a powerful technology: WebSockets.

I've worked with WebSockets in a bunch of different ways—from building real-time collaborative coding tools to developing systems for live rule validation, and even experimenting with AI-driven sign language translation. These projects have given me a much deeper appreciation for how WebSockets can bring interactive, real-time experiences to life. This post shares what I learned, breaks down the WebSocket protocol, and offers practical guidance on when—and when not—to use this technology.

What Are WebSockets?
WebSockets vs. HTTP / HTTPS: The Key Differences
The Technical Breakdown
Real-World Examples Where I Used WebSockets
When to Use WebSockets
When NOT to Use WebSockets
Implementation Guide
Alternatives to Consider
Conclusion

What Are WebSockets?

WebSockets provide a persistent, bidirectional communication channel between client and server over a single TCP connection. Unlike traditional HTTP's request-response model, WebSockets enable real-time data exchange without repeatedly opening and closing connections.

WebSockets vs. HTTP / HTTPS: The Key Differences

Feature	WebSockets	HTTP / HTTPS
Connection	Persistent	Temporary (opens & closes per request)
Communication	Full-duplex (simultaneous bidirectional)	Unidirectional request-response
Headers	Sent only during initial handshake	Sent with every request
Latency	Lower	Higher
Overhead	Minimal after handshake	Higher per message
Best for	Real-time applications, live updates	Traditional web pages, REST APIs

Diagram showing the key differences between HTTP/HTTPS and WebSockets communication patterns. HTTP uses a request-response model with new connections for each interaction, while WebSockets maintain a persistent connection allowing bidirectional communication.

The Technical Breakdown

WebSocket Protocol Basics

WebSockets begin life as an HTTP request with an Upgrade header. When the server accepts, the connection "upgrades" to the WebSocket protocol (ws:// or secure wss://), enabling the persistent connection that makes WebSockets powerful.

The Handshake Process

// Client initiates the handshake
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

// Server accepts the upgrade
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

After this exchange, the HTTP connection is replaced by a WebSocket connection using the same underlying TCP/IP connection.

Timing diagram illustrating the WebSocket connection lifecycle: initial HTTP handshake, protocol upgrade, bidirectional message exchange, and eventual connection closure. This visualizes how a single connection remains open for extended communication.

Full-Duplex Communication

Once established, both client and server can send messages independently without waiting for a request or response. This is what enables real-time applications to feel truly "live."

Unlike HTTP, where the client always initiates communication, WebSockets allow servers to push data to clients whenever new information is available. This bidirectional nature eliminates the need for polling and significantly reduces latency—updates appear almost instantly rather than after the next scheduled check.

Real-World Examples Where I Used WebSockets

These are the projects which made for either hackathon or as a personal project.

TechTriview: Interview Platform with Live Collaborative Coding & Whiteboard

TechTriview is a remote technical interview platform where interviewers and candidates can collaborate in real-time on coding problems and whiteboard sketches.

How WebSockets Were Used:

Keypresses and edits were broadcast live between users in the code editor.
Cursor positions were synchronized across clients for smooth collaboration.
Drawing events on the whiteboard were streamed to maintain an up-to-date canvas.

Why WebSockets worked well here:

The low latency and persistent connection created a smooth, collaborative experience that HTTP polling couldn't match.

Madhyam: Real-Time Sign Language Translator

Madhyam is an AI-powered translator that converts sign language into speech and text, enabling real-time communication between hearing and non-hearing individuals.

How WebSockets Were Used:

Live camera frames were streamed to the server via Flask-SocketIO.
The backend AI model processed frames and returned results instantly.
Text and synthesized speech were pushed back to the client without delay.
Two-way conversation was supported by transmitting speech recognition outputs.
- Why WebSockets Were Important:

The entire application depended on maintaining state and keeping low latency. Traditional HTTP would have introduced intolerable delays and connection overhead, as using AI itself takes time. Since AI inference already introduces some delay, fast communication over WebSockets was critical to keeping the overall experience smooth and responsive.

Security Rule Engine: Real-Time Rule Validation

This tool monitors incoming data streams and applies security rules in real-time. The dashboard shows security analysts which rules are being triggered as events occur:

Server continuously pushes new rule violations to connected clients
Analysts see triggered rules without refreshing the page
System can push urgent notifications when critical rules are violated
Historical data and trends update dynamically as new events arrive
Rule modification by one analyst is instantly visible to all team members

Why WebSockets were essential: The near-instant notification of security events couldn't tolerate the delay of traditional HTTP approaches. In security operations, seconds matter, and WebSockets provided the immediacy needed for effective incident response.

When to Use WebSockets

WebSockets shine in these scenarios:

Real-time collaborative applications
- Document editors (Google Docs, Notion)
- Whiteboarding tools
- Pair programming platforms
- Version control visualization systems
- Live collaborative design tools
Live data and monitoring
- Trading platforms with price tickers
- IoT device monitoring
- Server health dashboards
- Network traffic analyzers
- Industrial control systems
Interactive experiences
- Multiplayer games
- Live audience participation tools
- Real-time polls and voting systems
- Interactive presentations
- Virtual events with audience interaction
Chat and messaging
- Instant messaging apps
- Customer support live chat
- Team communication tools
- Video conferencing text chat
- Community discussion platforms
Notifications and alerts
- System alerts requiring immediate attention
- Social media notifications
- Real-time comment systems
- Status updates for long-running processes
- Emergency alert systems

When NOT to Use WebSockets

Despite their power, WebSockets aren't always the right choice:

Standard request-response scenarios
- Traditional CRUD applications
- Form submissions
- Static content delivery
- Authentication flows
- Payment processing
Low-frequency updates
- Daily data syncs
- Applications where a few seconds delay is acceptable
- When simple polling every few seconds works fine
- Infrequent notifications
- Batch processing systems
Resource-constrained environments
- Applications with thousands of concurrent users on limited server resources
- Mobile apps where battery life is a primary concern
- Scenarios where the overhead of maintaining persistent connections exceeds benefits
- Edge computing with limited memory
- Low-bandwidth or metered network environments
Simple HTTP APIs
- RESTful services that don't require push notifications
- Third-party API integrations that follow request-response patterns
- Stateless microservices
- Content distribution networks
- Traditional web applications with page refreshes

Implementation Guide

Basic Setup with Native WebSockets

Server (Node.js with ws package)

const WebSocket = require('ws');
const server = new WebSocket.Server({ port: 8080 });

server.on('connection', (socket) => {
  console.log('Client connected');

  // Handle incoming messages
  socket.on('message', (message) => {
    console.log(`Received: ${message}`);

    // Broadcast to all clients
    server.clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(`Server: ${message}`);
      }
    });
  });

  socket.on('close', () => {
    console.log('Client disconnected');
  });
});

Client (Browser JavaScript)

// Establish connection
const socket = new WebSocket('ws://localhost:8080');

// Connection opened
socket.addEventListener('open', (event) => {
  console.log('Connected to WebSocket server');
  socket.send('Hello Server!');
});

// Listen for messages
socket.addEventListener('message', (event) => {
  console.log('Message from server:', event.data);
});

// Handle errors
socket.addEventListener('error', (event) => {
  console.error('WebSocket error:', event);
});

// Connection closed
socket.addEventListener('close', (event) => {
  console.log('Server connection closed');
});

// To send a message
function sendMessage(message) {
  socket.send(message);
}

Using Socket.IO (Higher-level abstraction)

Socket.IO provides additional features like automatic reconnection, fallbacks to HTTP long-polling, and room-based broadcasting.

Server

const { createServer } = require('http');
const { Server } = require('socket.io');

const httpServer = createServer();
const io = new Server(httpServer, {
  cors: {
    origin: "http://localhost:3000",
    methods: ["GET", "POST"]
  }
});

io.on("connection", (socket) => {
  console.log(`Client connected: ${socket.id}`);

  // Join a room
  socket.on("join_room", (room) => {
    socket.join(room);
    console.log(`User ${socket.id} joined room: ${room}`);
  });

  // Handle messages
  socket.on("message", (data) => {
    console.log(`Message in ${data.room}: ${data.message}`);
    // Send to all clients in room except sender
    socket.to(data.room).emit("message", {
      sender: socket.id,
      message: data.message,
      timestamp: new Date()
    });
  });

  // Handle disconnection
  socket.on("disconnect", () => {
    console.log(`Client disconnected: ${socket.id}`);
  });
});

httpServer.listen(3001, () => {
  console.log("Server running on port 3001");
});

Client (React example)

import { useEffect, useState } from 'react';
import { io } from 'socket.io-client';

function ChatRoom({ room }) {
  const [socket, setSocket] = useState(null);
  const [messages, setMessages] = useState([]);
  const [inputValue, setInputValue] = useState('');

  useEffect(() => {
    // Initialize socket connection
    const newSocket = io('http://localhost:3001');
    setSocket(newSocket);

    // Join the specific room
    newSocket.emit('join_room', room);

    // Listen for messages
    newSocket.on('message', (message) => {
      setMessages((prevMessages) => [...prevMessages, message]);
    });

    // Cleanup on unmount
    return () => {
      newSocket.disconnect();
    };
  }, [room]);

  const sendMessage = (e) => {
    e.preventDefault();
    if (inputValue.trim() && socket) {
      socket.emit('message', {
        room,
        message: inputValue
      });
      setInputValue('');
    }
  };

  return (
    <div className="chat-room">
      <h2>Room: {room}</h2>
      <div className="message-list">
        {messages.map((msg, index) => (
          <div key={index} className="message">
            <span className="sender">{msg.sender}: </span>
            <span className="text">{msg.message}</span>
            <span className="time">{new Date(msg.timestamp).toLocaleTimeString()}</span>
          </div>
        ))}
      </div>
      <form onSubmit={sendMessage}>
        <input
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
          placeholder="Type a message..."
        />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

Python Implementation with Flask-SocketIO

from flask import Flask
from flask_socketio import SocketIO, emit

app = Flask(__name__)
socketio = SocketIO(app, cors_allowed_origins="*")

# Store active connections
active_users = {}

@app.route('/')
def index():
    return "Socket Server is Running!"

# When a client connects
@socketio.on('connect')
def handle_connect():
    print(f"Client connected: {request.sid}")
    active_users[request.sid] = {"status": "connected"}

# When a client disconnects
@socketio.on('disconnect')
def handle_disconnect():
    print(f"Client disconnected: {request.sid}")
    if request.sid in active_users:
        del active_users[request.sid]

# Handling custom message from the client
@socketio.on('custom_message')
def handle_custom_message(data):
    print(f"Received message from {request.sid}: {data}")

    # Send a response back to the client
    emit('response', {'message': f"Hello, {data['name']}! This is your response."})

# Handling broadcast messages to all connected clients
@socketio.on('broadcast_message')
def handle_broadcast(data):
    print(f"Broadcasting message: {data}")

    # Send the message to all connected clients
    emit('broadcast_response', {'message': data['message']}, broadcast=True)

if __name__ == '__main__':
    socketio.run(app, debug=True, host='0.0.0.0', port=5000)

Alternatives to Consider

WebSockets aren't the only option for real-time communication. Here are some alternatives worth considering:

Server-Sent Events (SSE)

SSE provides a one-way communication channel from server to client. It's simpler than WebSockets and works over standard HTTP connections, making it easier to implement for scenarios where you only need server-to-client updates. SSE automatically reconnects when connections are dropped and provides built-in event ID and retry logic.

HTTP Long Polling

Long polling involves the client making an HTTP request to the server, which holds the request open until new data is available. Once data is sent back, the client immediately sends another request. While not as efficient as WebSockets, it's more widely supported and can be easier to implement for simple use cases.

HTTP/2 Server Push

HTTP/2 allows servers to proactively send resources to clients before they're explicitly requested. This can be used to implement real-time updates in some cases, though it's primarily designed for resource optimization rather than real-time communication.

GraphQL Subscriptions

GraphQL subscriptions provide a structured, type-safe approach to real-time data. They allow clients to subscribe to specific events or data changes through a well-defined schema, often using WebSockets as the underlying transport mechanism.

Conclusion

WebSockets provide powerful real-time capabilities that transform user experiences, but they come with complexity and resource considerations. After building TechTriview, Madhyam, and the Security Rule Engine, I've learned that choosing the right communication protocol is as much about understanding your application's needs as it is about technical implementation.

When evaluating WebSockets for your project, consider:

How critical is real-time functionality to your user experience?
What's the expected message frequency and payload size?
How many concurrent connections will you need to support?
What are your scaling requirements?
Are there simpler alternatives that might meet your needs?

By answering these questions honestly, you'll make better architectural decisions that balance user experience with technical complexity.

Have you implemented WebSockets in your applications? What challenges did you face? Share your experiences in the comments!

DEV Community