Использовали ли вы собственный WebSocket или готовые решения

Что проверяют

Понимаете ли вы, что стоит за realtime на фронтенде, кроме new WebSocket(url). Какой бы вариант вы ни выбрали, следом спросят, как вы обрабатывали обрыв соединения и что происходило с сообщениями, пришедшими за это время.

Как отвечать

Расскажите свой случай: задача (чат, уведомления, котировки), что выбрали и почему. Затем покажите, что знаете обе стороны:

• нативный WebSocket: API браузера без зависимостей, но всё остальное на вас. Переподключение с экспоненциальной задержкой и случайным разбросом, heartbeat на уровне приложения (из JS нельзя отправить ping-кадр протокола), очередь исходящих на время обрыва, повторная подписка на каналы и досинхронизация пропущенного через REST по последнему id события;
• авторизация: браузерный WebSocket не даёт задать свои заголовки, поэтому токен едет в cookie, в первом сообщении или в query-параметре. Последний вариант попадает в логи прокси;
• Socket.IO: свой протокол поверх WebSocket с резервным long polling, комнатами, подтверждениями и автопереподключением. С обычным WS-сервером несовместим, серверная часть нужна своя;
• другие варианты: SignalR под бэкенд на .NET, Centrifugo как отдельный сервер, управляемые Ably и Pusher. Для однонаправленного потока хватит SSE через EventSource, который переподключается сам.

Для React упомяните архитектуру: одно соединение на приложение в отдельном модуле или контексте, компоненты подписываются на каналы и отписываются в cleanup useEffect. В dev-режиме StrictMode монтирует эффекты дважды, и без cleanup откроются два соединения.

Если опыта не было, скажите честно и объясните, как бы выбирали: для уведомлений SSE, для чата библиотека, самописная обёртка только когда понятно, что она должна уметь.

Где спотыкаются

Считают Socket.IO просто удобной обёрткой и пытаются подключить его клиент к голому WebSocket-серверу.

Не думают о пропущенных сообщениях: соединение восстановилось, а события за минуту обрыва потеряны без следа.

Открывают сокет в каждом компоненте и не закрывают его при размонтировании, получая утечки и дубли сообщений.