Розробка WebSocket API для мобільного застосунку
WebSocket API для мобільного застосунку проектується інакше, ніж для веб-клієнта. Головне відмінність — мобільний застосунок постійно втрачає з'єднання: переключення мереж, Doze Mode на Android, фоновий режим iOS. API має бути спроектований так, щоб клієнт міг переподключитися та отримати все пропущене без втрат.
Протокол поверх WebSocket
Raw WebSocket — це транспорт, не протокол. Поверх нього потрібно визначити формат повідомлень:
{
"type": "message.new",
"id": "uuid-v4",
"payload": { ... },
"timestamp": 1711234567890
}
type — маршрутизація на клієнті. id — ідемпотентність: клієнт ігнорує дублі при переподключенні. timestamp — для синхронізації стану.
Популярні протоколи поверх WebSocket: STOMP (добре працює з Spring Boot, багата екосистема клієнтів), Socket.IO (підтримка fallback на polling, кімнати з коробки, але привязує до JS-екосистеми), власний протокол (максимальний контроль, але більше роботи на всіх рівнях).
Reconnect та відновлення стану
Клієнт має переподключуватися автоматично. Але просто переподключення — недостатньо. Потрібно відати клієнту події, які він пропустив.
Серверна сторона: кожна подія має монотонно зростаючий sequence або cursor. При переподключенні клієнт відправляє останній отриманий cursor:
{ "type": "subscribe", "channel": "chat.123", "lastSeq": 4521 }
Сервер відповідає подіями з seq > 4521. Вікно зберігання — зазвичай 24–72 години. Якщо клієнт був відключений довше — відправляємо повний снапшот стану.
Без цієї механіки кожен розрив з'єднання означає пропущені повідомлення — особливо критично на Android з Doze Mode.
Аутентифікація та авторизація
WebSocket-з'єднання аутентифікується при handshake через query parameter або перше повідомлення:
wss://api.example.com/ws?token=eyJ...
Query-параметр простіше, але токен потрапляє в логи. Переважніше: встановити з'єднання, потім відправити auth фрейм з токеном, чекати auth_ok від сервера перед будь-якими підписками.
Істечення токена за час сесії — реальний сценарій. Сервер має відправляти token_expiring попередження за 60 секунд до істечення, клієнт оновлює токен та відправляє новий auth фрейм без розриву з'єднання.
Масштабування на бекенді
Одна інстанція сервера не може тримати з'єднання всіх клієнтів. При горизонтальному масштабуванні повідомлення, що прийшло на сервер A, має дійти до клієнтів на серверах B та C. Стандартне рішення — pub/sub через Redis (PUBLISH/SUBSCRIBE). Кожен сервер підписується на каналах та форвардить повідомлення своїм WebSocket-клієнтам.
Інфраструктурні альтернативи: Ably (hosted WebSocket infrastructure), Pusher Channels, AWS API Gateway WebSocket — знімають операційну навантаження за рахунок вартості та меншого контролю.
Клієнтська реалізація
На Android — OkHttp WebSocket з pingInterval для heartbeat. На iOS — URLSessionWebSocketTask. Деталі реалізації клієнта описані в статті про WebSocket-чат. Тут важливо: при проектуванні API потрібно одразу договоритися про максимальний розмір повідомлення (WebSocket frame limit), формат помилок та graceful закриття з'єднання (1000 Normal Closure vs 1011 Internal Error).
Що входить у роботу
Проектуємо протокол поверх WebSocket, реалізуємо server-side з механікою replay, аутентифікацією та heartbeat, інтегруємо клієнтський SDK під потрібні платформи. Документуємо всі типи подій.
Строк: 6–12 днів з урахуванням серверної частини та тестування на нестійких мережах.