Розробка WebSocket API для веб-додатків під ключ

Розробка WebSocket API для веб-додатків під ключ

Уявіть: ваш чат або дашборд гальмує через polling-запити кожні 500 мс. Користувачі скаржаться на затримки, а бекенд захлинається від N+1 запитів. Рішення — WebSocket: постійне з'єднання із затримкою менше 10 мс замість секунд. Заміна polling на WebSocket знижує навантаження на мережу та сервер у 10–20 разів, а також скорочує витрати на серверну інфраструктуру в 3-5 разів і економить до 90% трафіку. Ми розробляємо такі realtime-системи вже понад 10 років і реалізували 40+ проєктів для чатів, сповіщень та спільної роботи. Двонаправлений зв'язок по WebSocket дозволяє миттєво передавати оновлення котирувань, курсори або ігрові події — без зайвого оверхеду.

Які проблеми вирішує WebSocket API?

• Висока затримка при опитуванні: polling кожні 2 секунди дає лаг до 2000 мс, WebSocket — одиниці мілісекунд.
• Надлишковий трафік: кожен poll-запит надсилає HTTP-заголовки (700+ байт), WebSocket — лише дані (кілька байт).
• Складність із realtime-функціями: сповіщення, курсори, котирування — polling неефективний.
• Розриви з'єднання: мобільні мережі та проксі закривають idle-канали — потрібен heartbeat.
• Масштабування: один сервер не витримує >10 тис. конектів — потрібна кластеризація з Redis Pub/Sub.

Як ми розробляємо WebSocket-рішення

Починаємо з архітектурного проєктування: обираємо протокол (нативний WebSocket або Socket.io), визначаємо модель повідомлень (JSON-схеми), продумуємо аутентифікацію та вирішуємо питання масштабування. Нещодавно ми реалізували WebSocket-сервер для фінтех-стартапу: 50K одночасних підключень, затримка менше 10 мс, повне резервування через Redis кластер. Нижче — типовий підхід.

Базова реалізація з кімнатами (Node.js + ws)

import { WebSocketServer } from 'ws';
import { createServer } from 'http';

const server = createServer(app);
const wss = new WebSocketServer({ server });
const rooms = new Map<string, Set<WebSocket>>();

wss.on('connection', (ws, req) => {
  const roomId = new URL(req.url!, 'http://x').searchParams.get('room');
  if (!roomId) return ws.close(4000, 'Missing room');
  if (!rooms.has(roomId)) rooms.set(roomId, new Set());
  rooms.get(roomId)!.add(ws);

  ws.on('message', (data) => {
    const message = JSON.parse(data.toString());
    rooms.get(roomId)?.forEach(client => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify(message));
      }
    });
  });

  ws.on('close', () => {
    rooms.get(roomId)?.delete(ws);
  });
});

Повідомлення структуруємо в типізований JSON-протокол: { type, roomId, data, timestamp }. Це спрощує налагодження та обробку.

Аутентифікація та безпека

Оскільки WebSocket не підтримує кастомні заголовки при handshake, використовуємо перше повідомлення для аутентифікації — надсилаємо токен одразу після підключення. Якщо токен невалідний — закриваємо з'єднання з кодом 4001.

ws.on('connection', (socket) => {
  let authenticated = false;
  const authTimeout = setTimeout(() => {
    if (!authenticated) socket.close(4001, 'Auth timeout');
  }, 5000);
  socket.once('message', (data) => {
    const { type, token } = JSON.parse(data.toString());
    if (type === 'auth' && validateToken(token)) {
      authenticated = true;
      clearTimeout(authTimeout);
      socket.send(JSON.stringify({ type: 'auth_success' }));
    } else {
      socket.close(4001, 'Invalid token');
    }
  });
});

Цей підхід безпечніший за query-рядок, оскільки токен не світиться в логах.

Горизонтальне масштабування через Redis Pub/Sub

При кластеризації клієнти розподіляються по різних серверах. Щоб повідомлення від клієнта на сервері 1 дійшло до клієнта на сервері 2, використовуємо Redis Pub/Sub:

import { createClient } from 'redis';
const pub = createClient();
const sub = createClient();

ws.on('message', async (data) => {
  await pub.publish(`room:${roomId}`, data.toString());
});

sub.subscribe(`room:${roomId}`, (message) => {
  rooms.get(roomId)?.forEach(client => {
    if (client.readyState === WebSocket.OPEN) client.send(message);
  });
});

Redis працює як шина — всі сервери отримують події та доставляють їх своїм клієнтам. Це перевірене рішення, що витримує 100K+ підключень.

Як вибрати між Socket.io та нативним WebSocket?

Для проєктів із числом з'єднань до 10 тис. і нежорсткими вимогами до затримки Socket.io зручніший. Нативний WebSocket кращий при >10 тис. конектів, мінімальному оверхеді та повному контролі над протоколом.

Чому важливий heartbeat?

Браузери та проксі закривають idle-з'єднання через 20–120 секунд. Heartbeat (ping/pong) кожні 30 секунд підтримує канал живим і детектує розриви. Без нього клієнти «зависають» у списку користувачів.

wss.on('connection', (ws) => {
  let alive = true;
  ws.on('pong', () => {
    alive = true;
  });
  const interval = setInterval(() => {
    if (!alive) return ws.terminate();
    alive = false;
    ws.ping();
  }, 30000);
  ws.on('close', () => clearInterval(interval));
});

import { WebSocketServer } from 'ws';
import { createServer } from 'http';

const server = createServer();
const wss = new WebSocketServer({ server });

wss.on('connection', (socket, req) => {
  const roomId = new URL(req.url!, 'http://x').searchParams.get('room');
  if (!roomId) {
    socket.close(4000, 'Missing room');
    return;
  }

  let authenticated = false;
  const authTimeout = setTimeout(() => {
    if (!authenticated) socket.close(4001, 'Auth timeout');
  }, 5000);

  socket.once('message', (data) => {
    const { type, token } = JSON.parse(data.toString());
    if (type === 'auth' && validateToken(token)) {
      authenticated = true;
      clearTimeout(authTimeout);
      socket.send(JSON.stringify({ type: 'auth_success' }));
    } else {
      socket.close(4001, 'Invalid token');
    }
  });

  let alive = true;
  socket.on('pong', () => {
    alive = true;
  });

  const heartbeat = setInterval(() => {
    if (!alive) {
      socket.terminate();
      return;
    }
    alive = false;
    socket.ping();
  }, 30000);

  socket.on('close', () => {
    clearInterval(heartbeat);
    clearTimeout(authTimeout);
  });
});

server.listen(8080);

Процес роботи

1. Аналіз та прототип — визначаємо навантаження, сценарії, протокол повідомлень.
2. Проєктування — архітектура, вибір стеку, схема аутентифікації.
3. Розробка — реалізація сервера, клієнта, інтеграція з Redis.
4. Тестування — навантажувальні тести (10K+ конектів), тести на відмовостійкість.
5. Деплой та моніторинг — CI/CD, SRE-дашборди, алерти за затримками.

Що входить в роботу

• Повна архітектурна документація (PDF/Markdown)
• Репозиторій із серверним та клієнтським кодом (TypeScript)
• Інтеграція з Redis Pub/Sub для масштабування
• Налаштування heartbeat та механізму reconnect
• Інструкція з деплою на вашу інфраструктуру
• 1 місяць безкоштовної підтримки після релізу

Строки розробки

• MVP з кімнатами та аутентифікацією: 2–3 тижні
• Повноцінне рішення з Redis, тестами та документацією: від 3 до 5 тижнів

Точні строки залежать від складності протоколу та необхідного навантаження. Оцінимо ваш проєкт — зв'яжіться з нами. Замовте розробку WebSocket API, і ми гарантуємо стабільне з'єднання навіть при пікових навантаженнях.

WebSocket протокол описаний в RFC 6455.