웹소켓 실시간 앱: 매트릭스처럼 채팅 만들기

The Quest Begins (The “Why”)

Ever felt like you’re stuck in a refresh‑loop hell, hammering F5 just to see if someone replied to your message? I’ve been there. A few months ago I was building a simple internal tool for my team—a place where devs could drop quick status updates and get instant feedback. The first version used plain AJAX polling: every 2 seconds the client begged the server, “Anything new?” It worked… until the team grew. Suddenly we were spamming the server with hundreds of requests per minute, the UI felt jittery, and the poor DevOps guy started side‑eyeing our logs. That’s when the realization hit: we needed a true two‑way conversation, not a never‑ending game of “are we there yet?”. Enter WebSockets—the magical tunnel that lets client and server chat whenever they have something to say, without the constant knocking.

The Revelation (The Insight)

The big “aha!” moment came when I realized WebSockets aren’t just for chat. They’re a bidirectional, low‑latency pipe that can push any kind of data: notifications, live dashboards, collaborative editors, even multiplayer game state. Once the connection is opened with a simple handshake (the server says “I’m ready”, the client replies “Me too”), both sides can fire messages at will. No more polling, no more wasted bandwidth—just pure, real‑time flow.

What surprised me was how straightforward the API feels once you get past the handshake drama. On the client you create a WebSocket object, attach onopen, onmessage, onerror, and onclose handlers, and you’re off to the races. On the server side (I went with Node.js and the ws library for simplicity, but Socket.io works just as well) you listen for connection events, then treat each socket like a stream you can .send() to and .on('message', ...) from. The mental model is basically “walkie‑talkie”: press to talk, release to listen, but both parties can talk at the same time.

Wielding the Power (Code & Examples)

Let’s build a tiny chat room that also pushes notifications when someone joins or leaves. I’ll show the struggle first (the polling version) and then the victory (WebSocket version). Keep an eye out for the classic traps—missing heartbeat handling and forgetting to broadcast to all clients.

The Struggle: Polling AJAX (the “before”)

// client.js – polling every 2 seconds
let lastId = 0;
function fetchMessages() {
  fetch(`/api/messages?since=${lastId}`)
    .then(r => r.json())
    .then(data => {
      data.forEach(m => {
        appendMessage(m);
        lastId = m.id; // move the cursor forward
      });
    })
    .catch(console.error);
}
setInterval(fetchMessages, 2000);

Enter fullscreen mode Exit fullscreen mode

Trap #1: The server does nothing when a client connects or disconnects, so we have no way to know when a user shows up or vanishes without another poll.

Trap #2: If the network blips, we just keep hammering the endpoint, wasting bandwidth and potentially overwhelming the server.

The Victory: WebSocket Magic (the “after”)

Server (Node.js + ws)

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

// Keep track of all connected clients for broadcasting
const clients = new Set();

wss.on('connection', ws => {
  console.log('🟢 New client connected');
  clients.add(ws);

  // Send a join notification to everyone *except* the newcomer
  const joinMsg = { type: 'system', text: 'A user has joined the chat' };
  broadcast(JSON.stringify(joinMsg), ws);

  ws.on('message', raw => {
    const data = JSON.parse(raw);
    // Expect {type: 'chat', text: 'hello'}
    if (data.type === 'chat') {
      const out = JSON.stringify({type: 'chat', user: data.user, text: data.text});
      broadcast(out, ws); // echo to all, including sender (you can filter if you prefer)
    }
  });

  ws.on('close', () => {
    console.log('🔴 Client disconnected');
    clients.delete(ws);
    const leaveMsg = {type: 'system', text: 'A user has left the chat'};
    broadcast(JSON.stringify(leaveMsg));
  });

  ws.on('error', err => {
    console.error('WebSocket error:', err);
    ws.close();
  });
});

function broadcast(message, exceptWs = null) {
  for (const ws of clients) {
    if (ws !== exceptWs && ws.readyState === WebSocket.OPEN) {
      ws.send(message);
    }
  }
}

Enter fullscreen mode Exit fullscreen mode

Why this works:

• The connection event gives us a live socket per user.
• We store each socket in a Set so we can push messages to everyone instantly.
• Join/leave notices are broadcast the moment the socket appears or disappears—no polling needed.
• The exceptWs flag lets us avoid sending a join message back to the person who just joined (feels less noisy).

Client (plain JavaScript)

// client.js
const ws = new WebSocket('ws://localhost:8080');

ws.onopen = () => {
  console.log('✅ Connected to chat server');
  // Tell the server our username (could come from a prompt or auth token)
  ws.send(JSON.stringify({type: 'chat', user: 'Ada', text: 'has entered the room'}));
};

ws.onmessage = event => {
  const msg = JSON.parse(event.data);
  if (msg.type === 'chat') {
    appendMessage(`${msg.user}: ${msg.text}`);
  } else if (msg.type === 'system') {
    appendSystem(msg.text); // styled differently, e.g., grey italic
  }
};

ws.onclose = () => {
  console.log('❌ Disconnected');
  appendSystem('You have been disconnected from the chat');
};

ws.onerror = err => {
  console.error('WebSocket error:', err);
};

Enter fullscreen mode Exit fullscreen mode

Trap #2 (again, but now avoided): Forgetting to check ws.readyState === WebSocket.OPEN before sending can lead to silent errors if you try to message after a network hiccup. The server’s broadcast helper guards against that, and on the client we rely on the built‑in onclose/onerror to clean up.

Live Updates & Notifications

The same pattern works for anything else:

• Notifications: Instead of a chat type, push {type: 'notify', payload: {...}} and render a toast.
• Live dashboard: Send {type: 'metric', name: 'cpu', value: 57} and update a chart in real time.
• Collaborative editing: Diff‑based ops flow over the socket, giving that Google Docs feel.

All of it lives on the same open connection—no extra HTTP overhead, no race conditions from staggered polls.

Why This New Power Matters

Now that you’ve got the WebSocket spell in your toolbox, the kinds of apps you can build feel alive. Imagine a support portal where agents see customer queries pop up the instant they’re typed, a stock ticker that streams price changes without a refresh, or a multiplayer quiz where everyone’s answers appear in real time. The barrier between “server pushes data” and “client reacts instantly” disappears, and the user experience jumps from “waiting for the next tick” to “feeling the pulse of the app”.

The best part? You don’t need a heavyweight framework to get started. A few lines of ws on the server and a WebSocket object on the client are enough to turn a static page into a living, breathing conversation. Once you’ve felt that first push notification arrive without a single setInterval, you’ll wonder why you ever settled for polling.

Your Turn: The Challenge

I dare you to take a simple TODO list you’ve built before and replace its “add item” button with a WebSocket broadcast. Whenever anyone adds a task, it should appear instantly on every other client’s screen—no refresh, no polling. Bonus: add a “user online” indicator that lights up when a socket opens and dims when it closes. Share your code snippet (or a gist) in the comments; I’d love to see what real‑time wizardry you conjure!

Go forth, open that socket, and let the data flow like a conversation between old friends. Happy coding! 🚀