## Why Normal HTTP Struggles with Real-Time Apps 🌐 HTTP works brilliantly for most websites and APIs, but its traditional communication model is **request → response**. The client asks for something, the server responds, and the request is finished. ```text Client ↓ GET /messages ↓ Server ↓ Response ``` That works perfectly for loading profiles, products, articles or API data. But imagine you're building a chat app. A new message arrives on the server, and the server wants to tell the browser immediately. With normal request-response HTTP, the server usually needs the client to initiate another request first. ```text New message arrives on server ↓ Server wants to tell client ↓ Client hasn't asked anything 😅 ``` Real-time applications need a better communication model. Common examples include: * chat applications * live notifications * multiplayer games * collaborative editors * live dashboards * delivery tracking * trading interfaces * presence indicators --- ## The Old Solution: Polling 🔁 Before WebSockets became widely available, developers often used **polling**. The browser repeatedly asks: ```text Any new messages? Any new messages? Any new messages? Any new messages? ``` For example: ```javascript setInterval( async () => { const response = await fetch( '/api/messages' ); const messages = await response.json(); console.log( messages ); }, 3000 ); ``` This sends a request every three seconds whether anything changed or not. Imagine 100,000 connected users doing this continuously: ```text 100,000 users × Request every 3 seconds ↓ A lot of unnecessary traffic 💀 ``` Polling can still be useful in some situations, but it's inefficient for truly real-time communication. --- ## Long Polling ⏳ **Long polling** improves on normal polling. Instead of immediately responding with: ```text No new data ``` the server keeps the request open until something happens. ```text Client ↓ Request ↓ Server waits... Server waits... New message arrives! ↓ Response ``` The client receives the response and immediately opens another long-poll request. This reduces unnecessary empty requests, but you're still repeatedly creating HTTP request-response cycles. --- ## Server-Sent Events — SSE 📡 **Server-Sent Events (SSE)** let the server continuously send updates to the browser over an HTTP connection. They're great when communication mainly goes one direction: ```text Server ↓ ↓ ↓ Client ``` Examples include: * live news feeds * AI-generated text streaming * stock price updates * server logs * progress updates * notifications But SSE is primarily **server → client** communication. For something highly interactive like chat: ```text Client ↔ Server ``` WebSockets are usually a more natural fit. --- # Enter WebSockets ⚡ The **WebSocket protocol** provides a persistent, two-way communication channel between client and server. Instead of repeatedly doing: ```text Request Response Request Response Request Response ``` you establish one connection: ```text Client ↕ WebSocket ↕ Server ``` and keep it open. Both sides can send messages whenever they need to. --- ## Why WebSockets Are Useful 🚀 WebSockets have three important characteristics: ### Persistent The connection stays open instead of closing after every message. ### Full-Duplex Both sides can communicate independently. ```text Client ───────▶ Server Client ◀─────── Server ``` The server doesn't need to wait for the client to ask before sending an update. ### Low Message Overhead After the opening handshake, WebSocket messages use lightweight WebSocket frames rather than sending a complete normal HTTP request header set for every message. This makes WebSockets useful when lots of small real-time messages move back and forth. --- # HTTP vs WebSocket 🆚 A simple comparison: | Feature | HTTP API | WebSocket | | ------------------------- | ------------------------------------- | --------------------- | | Communication | Request → Response | Two-way | | Connection | Usually request-based | Persistent | | Server can push anytime | Not traditional HTTP request-response | Yes | | Great for [REST APIs](/courses/expressjs) | ✅ | Usually not needed | | Great for chat | Possible, but awkward | ✅ | | Live events | Polling/SSE possible | ✅ | | Repeated message overhead | Higher | Lower after handshake | WebSockets aren't a replacement for HTTP. A real application may use both: ```text HTTP → Login → Load profile → Fetch old messages → Upload image WebSocket → New messages → Typing indicator → Online status → Live notifications ``` Use the right tool for each job. --- # The WebSocket Handshake 🤝 Here's something interesting: a traditional WebSocket connection usually **starts as an HTTP request**. The browser sends an upgrade request containing headers similar to: ```http GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: random-value Sec-WebSocket-Version: 13 ``` The important part is: ```text Upgrade: websocket Connection: Upgrade ``` The client is basically saying: > Hey server, can we switch this connection from HTTP to WebSocket? If the server agrees, it responds: ```http HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: calculated-value ``` `101 Switching Protocols` means the upgrade succeeded. Conceptually: ```text HTTP Connection ↓ WebSocket upgrade request ↓ 101 Switching Protocols ↓ WebSocket Connection ⚡ ``` After that, both sides exchange WebSocket frames instead of normal request-response messages. --- # `ws://` vs `wss://` 🔐 WebSocket URLs commonly use: ```text ws:// ``` or: ```text wss:// ``` Think of them like: ```text http:// → ws:// https:// → wss:// ``` `wss://` uses TLS encryption and should be used in production. Example: ```text Development: ws://localhost:8080 Production: wss://api.example.com ``` For real production applications: ```text Use wss:// ✅ ``` --- # WebSockets in Node.js 🟢 Modern [Node.js](/courses/nodejs) includes a browser-compatible `WebSocket` API that can be used as a **client**. For example: ```javascript const socket = new WebSocket( 'wss://example.com' ); ``` But when you want [Node.js](/courses/nodejs) to **host a WebSocket server**, a common lightweight choice is the `ws` package. Install it: ```bash npm install ws ``` Import: ```javascript const WebSocket = require('ws'); ``` `ws` stays close to the WebSocket protocol and gives you the low-level pieces needed to build your own real-time architecture. --- # Creating a WebSocket Server 🚀 First create a normal HTTP server: ```javascript const http = require('http'); const server = http.createServer( (req, res) => { res.writeHead( 200, { 'Content-Type': 'text/plain' } ); res.end( 'WebSocket server running' ); } ); ``` Now attach a WebSocket server: ```javascript const WebSocket = require('ws'); const { WebSocketServer } = WebSocket; const wss = new WebSocketServer({ server }); ``` Both HTTP and WebSocket traffic can now share the same server and port. ```text localhost:8080 HTTP ↓ http://localhost:8080 WebSocket ↓ ws://localhost:8080 ``` --- # Listening for Connections 🔌 When a client connects: ```javascript wss.on( 'connection', (ws, req) => { console.log( 'New client connected' ); } ); ``` You can inspect information about the underlying connection: ```javascript const ip = req.socket .remoteAddress; console.log( 'Client IP:', ip ); ``` Then send the client a welcome message: ```javascript ws.send( JSON.stringify({ type: 'system', message: 'Welcome to the WebSocket server!' }) ); ``` WebSocket messages are often sent as JSON strings because JSON gives your application a clear message structure. --- # Designing WebSocket Messages 📦 Instead of sending only: ```text Hello ``` it's better to send structured messages: ```javascript { type: 'chat:message', sender: 'Alice', message: 'Hello!' } ``` Then: ```javascript ws.send( JSON.stringify({ type: 'chat:message', sender: 'Alice', message: 'Hello!' }) ); ``` The `type` field tells your application what kind of event arrived. For example: ```text chat:message user:typing user:online notification:new message:read ``` This becomes very useful as real-time applications grow. --- # Receiving Messages 📥 Listen for the `message` event: ```javascript ws.on( 'message', (data) => { const message = data.toString(); console.log( 'Received:', message ); } ); ``` If you're sending JSON: ```javascript ws.on( 'message', (data) => { try { const message = JSON.parse( data.toString() ); console.log( message.type, message.message ); } catch { console.log( 'Invalid JSON message' ); } } ); ``` Always treat incoming WebSocket messages just like normal API input: ```text Don't trust them. Validate them. 🛡️ ``` A connected user can still send bad or malicious data. --- # Broadcasting Messages 📢 Suppose Alice sends: ```text Hello everyone! ``` and you want every other connected client to receive it. The `ws` server tracks connected clients through: ```javascript wss.clients ``` So you can broadcast manually: ```javascript ws.on( 'message', (data, isBinary) => { for ( const client of wss.clients ) { if ( client !== ws && client.readyState === WebSocket.OPEN ) { client.send( data, { binary: isBinary } ); } } } ); ``` The flow becomes: ```text Alice ↓ Server ├──▶ Bob ├──▶ Charlie └──▶ David ``` Unlike higher-level frameworks such as Socket.IO, raw `ws` doesn't give you an application-level room system automatically. You build the organization your application needs. --- # Complete Raw WebSocket Server 🧱 Here's everything together: ```javascript const http = require('http'); const WebSocket = require('ws'); const { WebSocketServer } = WebSocket; const server = http.createServer( (req, res) => { res.writeHead( 200, { 'Content-Type': 'text/plain' } ); res.end( 'WebSocket server running' ); } ); const wss = new WebSocketServer({ server }); wss.on( 'connection', (ws, req) => { const ip = req.socket .remoteAddress; console.log( `✅ Connected: ${ip}` ); console.log( `Clients: ${wss.clients.size}` ); ws.send( JSON.stringify({ type: 'system', message: 'Welcome to the server!' }) ); ws.on( 'message', ( data, isBinary ) => { console.log( 'Received:', data.toString() ); for ( const client of wss.clients ) { if ( client !== ws && client.readyState === WebSocket.OPEN ) { client.send( data, { binary: isBinary } ); } } } ); ws.on( 'close', () => { console.log( '❌ Client disconnected' ); console.log( `Clients: ${wss.clients.size}` ); } ); ws.on( 'error', (error) => { console.error( 'WebSocket error:', error.message ); } ); } ); server.listen( 8080, () => { console.log( '🚀 HTTP: http://localhost:8080' ); console.log( '⚡ WS: ws://localhost:8080' ); } ); ``` You now have a basic real-time server. --- # Browser WebSocket Client 🌐 Browsers already provide a native WebSocket API. You don't need to install anything. ```javascript const ws = new WebSocket( 'ws://localhost:8080' ); ``` A WebSocket client commonly handles four things: ```text Connection opens Message arrives Connection closes Error happens ``` --- ## Connection Open ✅ ```javascript ws.onopen = () => { console.log( 'Connected!' ); }; ``` Once `onopen` fires, the WebSocket is ready to send messages. --- # Receiving Messages 📩 ```javascript ws.onmessage = (event) => { console.log( 'Received:', event.data ); }; ``` If your server sends JSON: ```javascript ws.onmessage = (event) => { try { const data = JSON.parse( event.data ); console.log( data ); } catch { console.log( event.data ); } }; ``` --- # Sending Messages 📤 Check that the connection is open: ```javascript function sendMessage( message ) { if ( ws.readyState !== WebSocket.OPEN ) { return; } const payload = JSON.stringify({ type: 'chat:message', message }); ws.send( payload ); } ``` Now: ```javascript sendMessage( 'Hello server!' ); ``` sends the message instantly over the existing connection. --- # WebSocket Ready States 🚦 A WebSocket has four main connection states: ```text CONNECTING → 0 OPEN → 1 CLOSING → 2 CLOSED → 3 ``` You can check: ```javascript if ( ws.readyState === WebSocket.OPEN ) { ws.send( 'Hello!' ); } ``` This prevents your application from trying to send through a closed connection. --- # Handling Disconnects ❌ Listen for: ```javascript ws.onclose = () => { console.log( 'Disconnected' ); }; ``` An important limitation of native WebSockets is that automatic application reconnection isn't built in. If Wi-Fi drops: ```text Connection ↓ 💥 Lost ``` your application needs to decide what happens next. You could reconnect manually: ```javascript function connect() { const ws = new WebSocket( 'ws://localhost:8080' ); ws.onclose = () => { setTimeout( connect, 3000 ); }; return ws; } ``` Real applications usually add smarter logic such as exponential backoff rather than retrying forever at a fixed interval. --- # Detecting Dead Connections 💓 Sometimes a network connection disappears without either side immediately realizing it. For example: ```text Laptop loses Wi-Fi ↓ Server still thinks client exists 😬 ``` WebSocket servers commonly use **ping/pong heartbeats** to detect these dead connections. With `ws`: ```javascript function heartbeat() { this.isAlive = true; } wss.on( 'connection', (ws) => { ws.isAlive = true; ws.on( 'pong', heartbeat ); } ); ``` Then periodically check clients: ```javascript const interval = setInterval( () => { wss.clients .forEach( (ws) => { if ( ws.isAlive === false ) { return ws .terminate(); } ws.isAlive = false; ws.ping(); } ); }, 30000 ); ``` The idea is: ```text Server → ping Client → pong ✅ No pong? → connection may be dead → close it ``` This becomes important when maintaining thousands of persistent connections. --- # A Simple Browser Chat 💬 Here's a small browser client: ```html

Raw WebSocket Chat

``` Notice that incoming messages are inserted using: ```javascript textContent ``` instead of blindly injecting message text with `innerHTML`. Messages arriving through WebSockets are still **untrusted user input** and must be handled safely. --- # Raw WebSockets vs Socket.IO 🤔 The `ws` package is intentionally lightweight. It gives you WebSocket communication, but higher-level features such as these are generally your responsibility: ```text Rooms Automatic application reconnection Acknowledgements Event naming conventions Presence management User mapping Message persistence Distributed broadcasting ``` Libraries such as **Socket.IO** build higher-level real-time features on top of their own client/server protocol and transport system. So: ```text ws → Low-level → Lightweight → More control → You build more yourself Socket.IO → Higher-level features → Rooms → Reconnection → Broadcasting helpers → Easier for many app workflows ``` Neither is always better. Understanding raw WebSockets first makes Socket.IO much easier to understand later. --- # Where WebSockets Fit in a Real App 🧠 Imagine a messaging application: ```text REST API ↓ Login User profile Old messages Upload attachments Search users WebSocket ↓ New message Typing indicator Online status Read receipt Incoming call Live notification ``` [REST](/courses/expressjs) handles normal resource operations beautifully. WebSockets handle events that need to arrive immediately. Together, they're extremely powerful. --- ## Quick Recap 🚀 The most important ideas from this chapter are: * 🌐 Traditional HTTP APIs mainly follow request-response communication. * 🔁 Polling repeatedly asks the server for updates. * ⏳ Long polling keeps requests open longer. * 📡 SSE is great for server-to-client streaming. * ⚡ WebSockets provide persistent two-way communication. * 🤝 WebSockets commonly begin with an HTTP upgrade handshake. * `101 Switching Protocols` means the WebSocket upgrade succeeded. * 🔐 Use `wss://` in production. * 🟢 Modern Node.js includes a WebSocket client API. * 🧩 `ws` is a popular lightweight choice for Node.js WebSocket servers. * 📢 Broadcasting can be built by iterating connected clients. * 💓 Ping/pong heartbeats help detect dead connections. * 🔁 Native WebSocket applications need their own reconnection strategy. * 🛡️ WebSocket messages must still be validated and safely rendered. The easiest mental model is: ```text HTTP → Ask me and I'll reply. WebSocket → We're connected — either of us can talk. 😎 ``` In the next chapter, we'll move from raw WebSockets to **Socket.IO**, where we'll explore events, broadcasting, rooms and namespaces. --- ## Keep Learning with asif.to 🚀 You now understand the communication model behind chat apps, live notifications and many other real-time systems. Explore more beginner-friendly Node.js tutorials, WebSocket guides, interview questions, cheatsheets and practical backend examples on **[asif.to](https://asif.to)**. Follow **asif.to** on social media for quick coding tips, developer content, new tutorials and course updates. 💻✨