Разработка 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 дней с учётом серверной части и тестирования на нестабильных сетях.