Setting up WebSocket server in Express - Mechanics & Internals

Overview - Setting up WebSocket server

What is it?

A WebSocket server allows real-time, two-way communication between a client and a server over a single connection. Unlike regular HTTP, WebSockets keep the connection open, so data can flow instantly in both directions. Setting up a WebSocket server means creating this persistent connection point on the server side using tools like Express and WebSocket libraries.

Why it matters

Without WebSocket servers, web apps would rely on slower, less efficient methods like repeated requests to check for updates. This causes delays and wastes resources. WebSocket servers enable instant updates, making apps like chats, games, and live feeds feel smooth and responsive. Without them, real-time experiences would be clunky or impossible.

Where it fits

Before learning this, you should understand basic Express server setup and HTTP concepts. After mastering WebSocket servers, you can explore advanced real-time features, scaling WebSocket connections, and integrating with frontend frameworks for interactive apps.

Mental Model

Core Idea

A WebSocket server keeps a single open connection with clients to send and receive messages instantly in both directions.

Think of it like...

It's like a phone call between two people instead of sending letters back and forth; once connected, they can talk anytime without hanging up and redialing.

Client ──────► WebSocket Server ──────► Client
   ▲                                ▲
   │                                │
   ◄───────── Messages Flow ───────►

Build-Up - 6 Steps

1

Foundation

Understanding HTTP vs WebSocket

Concept: Learn the difference between HTTP requests and WebSocket connections.

HTTP is like sending letters: each request opens a new connection, sends data, then closes. WebSocket is like a phone call: one connection stays open for continuous two-way talk.

Result

You see why WebSocket is better for instant, ongoing communication.

Understanding this difference explains why WebSocket servers are needed for real-time apps.

2

Foundation

Installing WebSocket libraries with Express

Concept: Learn how to add WebSocket support to an Express server using a library.

You install 'ws', a popular WebSocket library, with npm. Then you create an Express server and attach the WebSocket server to it.

Result

Your server can now accept WebSocket connections alongside normal HTTP requests.

Knowing how to combine Express and WebSocket libraries is the first step to real-time servers.

3

Intermediate

Creating a basic WebSocket server

🤔Before reading on: do you think the WebSocket server listens on the same port as Express or a different one? Commit to your answer.

Concept: Set up a WebSocket server that listens for client connections and handles messages.

You create a WebSocket server attached to the Express HTTP server. When a client connects, you listen for messages and can send replies.

Result

Clients can connect and exchange messages instantly with the server.

Understanding that WebSocket servers can share the same port as Express simplifies deployment.

4

Intermediate

Handling multiple clients and broadcasting

🤔Before reading on: do you think the server automatically sends messages to all clients or only the sender? Commit to your answer.

Concept: Manage multiple client connections and send messages to all or some clients.

You keep track of all connected clients. When one sends a message, you loop through clients to broadcast it, skipping closed connections.

Result

All connected clients receive real-time updates from each other.

Knowing how to broadcast messages is key to building chat rooms or live feeds.

5

Advanced

Integrating WebSocket with Express routes

🤔Before reading on: can Express routes and WebSocket messages share data easily? Commit to your answer.

Concept: Combine WebSocket communication with Express HTTP routes to share data or trigger events.

You can use shared variables or event emitters to connect Express route logic with WebSocket message handling, enabling complex interactions.

Result

Your app can respond to HTTP requests and push real-time updates via WebSocket seamlessly.

Understanding this integration enables richer, interactive web applications.

6

Expert

Scaling WebSocket servers in production

🤔Before reading on: do you think a single WebSocket server can handle thousands of clients easily? Commit to your answer.

Concept: Learn challenges and solutions for running WebSocket servers at scale across multiple machines.

A single server has limits. You use load balancers, sticky sessions, or message brokers like Redis to share client info across servers, ensuring all clients get messages.

Result

Your WebSocket service can support many users reliably and efficiently.

Knowing scaling techniques prevents common failures in real-time apps under heavy load.

Under the Hood

When a client requests a WebSocket connection, the server upgrades the HTTP connection to a WebSocket protocol. This upgrade keeps the TCP connection open, allowing both sides to send frames of data asynchronously. The server manages each connection's state and routes messages to the right clients.

Why designed this way?

WebSocket was designed to overcome HTTP's request-response limits by enabling persistent, full-duplex communication. It uses an initial HTTP handshake for compatibility, then switches protocols to maintain efficiency and real-time capability.

Client HTTP Request
      │
      ▼
[Server HTTP Upgrade]
      │
      ▼
[WebSocket Connection Established]
      │  ◄───────►
      │  Full-duplex data flow
      ▼
[Server manages multiple clients]

Myth Busters - 4 Common Misconceptions

Quick: Does a WebSocket server automatically reconnect clients if they disconnect? Commit to yes or no.

Common Belief: WebSocket servers handle client reconnections automatically without extra code.

Reality: Reconnections must be managed by the client; the server only accepts connections but does not reconnect clients.

Why it matters: Assuming automatic reconnection leads to lost connections and broken real-time features in unstable networks.

Quick: Can WebSocket servers only run on separate ports from HTTP servers? Commit to yes or no.

Common Belief: WebSocket servers must run on different ports than HTTP servers.

Reality: WebSocket servers can share the same port as HTTP servers by upgrading connections on that port.

Why it matters: Believing otherwise complicates deployment and increases resource use unnecessarily.

Quick: Does sending a message to one client automatically send it to all connected clients? Commit to yes or no.

Common Belief: When a client sends a message, the server automatically broadcasts it to all clients.

Reality: The server only sends messages to clients you explicitly code it to send to; broadcasting requires manual implementation.

Why it matters: Assuming automatic broadcast causes confusion and bugs in multi-client apps.

Quick: Is WebSocket just a fancy name for HTTP streaming? Commit to yes or no.

Common Belief: WebSocket is just HTTP streaming with a different name.

Reality: WebSocket is a distinct protocol with a handshake and full-duplex communication, unlike HTTP streaming which is one-way.

Why it matters: Confusing the two leads to wrong implementation choices and missed real-time benefits.

Expert Zone

1

WebSocket connections can carry binary data frames, not just text, enabling efficient transfer of images or files.

2

The initial HTTP upgrade handshake allows WebSocket to work through many firewalls and proxies that block unknown protocols.

3

Handling backpressure (when clients can't keep up with message flow) is critical to avoid memory leaks or crashes in production.

When NOT to use

WebSocket is not ideal for simple request-response APIs or when server push is unnecessary. Alternatives like HTTP/2 server push or long polling may be simpler for low-frequency updates.

Production Patterns

In production, WebSocket servers often use Redis or similar pub/sub systems to synchronize messages across multiple server instances. Load balancers with sticky sessions ensure clients stay connected to the same server. Monitoring connection health and implementing reconnection logic on clients are standard practices.

Connections

Event-driven programming

WebSocket servers rely on event-driven patterns to handle incoming messages and connections asynchronously.

Understanding event-driven programming helps grasp how WebSocket servers efficiently manage many clients without blocking.

TCP/IP networking

WebSocket connections run over TCP, maintaining a persistent socket between client and server.

Knowing TCP basics clarifies why WebSocket can send data instantly and reliably once connected.

Telephone communication systems

WebSocket's persistent two-way connection mirrors how telephone calls maintain open lines for conversation.

Recognizing this similarity helps understand the difference from stateless communication like letters or emails.

Common Pitfalls

#1 Not handling client disconnections properly

Wrong approach:

wss.on('connection', ws => {
ws.on('message', message => {
// process message
});
// no code to detect or handle 'close' event
});

Correct approach:

wss.on('connection', ws => {
ws.on('message', message => {
// process message
});
ws.on('close', () => {
// clean up resources or remove client from list
});
});

Root cause:

Beginners often forget that clients can disconnect anytime and the server must clean up to avoid memory leaks.

#2 Trying to send messages to clients without checking if connection is open

Wrong approach:

clients.forEach(client => {
client.send('Hello');
});

Correct approach:

clients.forEach(client => {
if (client.readyState === WebSocket.OPEN) {
client.send('Hello');
}
});

Root cause:

Not checking connection state causes errors when sending to closed sockets.

#3 Running WebSocket server on a different port without configuring CORS or proxies

Wrong approach:

const wss = new WebSocket.Server({ port: 8081 });
// Express runs on 8080
// No proxy or CORS setup

Correct approach:

const server = http.createServer(app);
const wss = new WebSocket.Server({ server });
server.listen(8080);

Root cause:

Beginners separate ports without handling cross-origin or proxy issues, causing connection failures.

Key Takeaways

WebSocket servers enable fast, two-way communication by keeping connections open between clients and servers.

They differ from HTTP by allowing instant message exchange without repeated connection setup.

Combining WebSocket with Express lets you build real-time features alongside traditional web routes.

Proper handling of multiple clients, connection states, and scaling is essential for reliable production apps.

Understanding the protocol's handshake and persistent connection model unlocks deeper control and optimization.

Practice

1. What is the main purpose of setting up a WebSocket server with Express?

easy

A. To enable real-time two-way communication between client and server

B. To serve static files like images and CSS

C. To handle database queries asynchronously

D. To render HTML templates on the server

Solution

1. Step 1: Understand WebSocket functionality

   WebSocket allows instant two-way communication between client and server, unlike HTTP which is one-way per request.

2. Step 2: Identify Express role

   Express is used to create the HTTP server, but WebSocket adds real-time messaging capability on top.

3. Final Answer:

   To enable real-time two-way communication between client and server -> Option A

4. Quick Check:

   WebSocket = real-time two-way communication [OK]

Hint: WebSocket means instant two-way chat between client and server [OK]

Common Mistakes:

• Confusing WebSocket with static file serving
• Thinking WebSocket handles database queries
• Assuming WebSocket renders HTML

2. Which code snippet correctly creates an HTTP server to use with WebSocket in Express?

easy

A. const server = http.createServer(app);

B. const server = express();

C. const server = new WebSocket.Server(app);

D. const server = express.createServer();

Solution

1. Step 1: Recognize Express app and HTTP server creation

   Express app is created by calling express(), but to use WebSocket, you need an HTTP server wrapping the app.

2. Step 2: Identify correct server creation method

   http.createServer(app) creates an HTTP server that can be shared with WebSocket.

3. Final Answer:

   const server = http.createServer(app); -> Option A

4. Quick Check:

   Use http.createServer(app) for WebSocket [OK]

Hint: Use http.createServer(app) to share server with WebSocket [OK]

Common Mistakes:

• Using express.createServer() which does not exist
• Creating WebSocket.Server with app directly
• Assigning express() to server without HTTP wrapper

3. Given this code snippet, what will be logged when a client sends the message 'Hello'?

const WebSocket = require('ws');
const http = require('http');
const express = require('express');
const app = express();
const server = http.createServer(app);
const wss = new WebSocket.Server({ server });
wss.on('connection', ws => {
  ws.on('message', message => {
    console.log(`Received: ${message}`);
  });
});
server.listen(3000);

medium

A. No output

B. message

C. Error: ws.on is not a function

D. Received: Hello

Solution

1. Step 1: Understand event listeners setup

   The server listens for 'connection' events, then for each connection listens for 'message' events.

2. Step 2: Analyze message event handler

   When a message arrives, it logs 'Received: ' plus the message content.

3. Final Answer:

   Received: Hello -> Option D

4. Quick Check:

   Message event logs 'Received: message' [OK]

Hint: Message event logs 'Received: ' plus message text [OK]

Common Mistakes:

• Expecting raw 'message' string without prefix
• Confusing event names or handlers
• Thinking ws.on is undefined

4. Identify the error in this WebSocket server setup code:

const WebSocket = require('ws');
const express = require('express');
const app = express();
const server = http.createServer();
const wss = new WebSocket.Server({ server });
server.listen(3000);

medium

A. WebSocket.Server should not receive server option

B. http module is not imported

C. express() should be passed to WebSocket.Server

D. server.listen should be called before creating WebSocket.Server

Solution

1. Step 1: Check module imports

   The code uses http.createServer() but does not import the 'http' module, causing a ReferenceError.

2. Step 2: Verify server creation and usage

   http.createServer() requires the http module; without import, server is undefined.

3. Final Answer:

   http module is not imported -> Option B

4. Quick Check:

   Missing http import causes error [OK]

Hint: Always import http before using http.createServer() [OK]

Common Mistakes:

• Forgetting to import http module
• Passing express app directly to WebSocket.Server
• Calling listen before server creation

5. You want to broadcast a message to all connected WebSocket clients when one client sends a message. Which code snippet correctly implements this inside the 'connection' event handler?

wss.on('connection', ws => {
  ws.on('message', message => {
    // Broadcast message to all clients
    ???
  });
});

hard

A. ws.clients.forEach(client => client.send(message));

B. wss.broadcast(message);

C. wss.clients.forEach(client => { if(client.readyState === WebSocket.OPEN) client.send(message); });

D. server.clients.forEach(client => client.send(message));

Solution

1. Step 1: Identify how to access all clients

   The WebSocket.Server instance 'wss' has a 'clients' set containing all connected clients.

2. Step 2: Filter clients by open connection and send message

   Only clients with readyState === WebSocket.OPEN can receive messages safely.

3. Final Answer:

   wss.clients.forEach(client => { if(client.readyState === WebSocket.OPEN) client.send(message); }); -> Option C

4. Quick Check:

   Broadcast uses wss.clients with readyState check [OK]

Hint: Use wss.clients and check readyState before sending [OK]

Common Mistakes:

• Using ws.clients which does not exist
• Calling non-existent broadcast method
• Accessing server.clients which is undefined