Розробка 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.