Специализация
Python Backend Developer
Java Backend Developer
Node.js Backend Developer
Golang Backend Developer
React Frontend Developer
Выберите навыки
React
JavaScript
Git
Redux
Webpack
Сложность
1-3
4-6
7-8
9-10
Рейтинг вопросов
1
2
3
4
5
Подпишись на React Developer в телеграм
Опиши реализацию long polling сервиса
Long polling — это техника, при которой клиент делает запрос и сервер не отвечает сразу, а ждёт события. После ответа клиент делает новый запрос. Это позволяет эмулировать "реальное время" без постоянного опроса.
Как получать информацию в реальном времени?
Для получения данных в реальном времени используют:
WebSocket – двустороннее соединение между клиентом и сервером.
Server-Sent Events (SSE) – поток односторонних сообщений от сервера.
Long Polling – запросы с долгим ожиданием ответа.
Объясни разницу между long-polling, WebSocket и gRPC stream. В каких кейсах каждый лучше?
Long-polling — имитация push через повторные запросы.
WebSocket — постоянное двунаправленное соединение поверх TCP.
gRPC stream — бинарный стриминг на HTTP/2.
Как работает механизм polling в сенсорах?
Polling — это периодическая проверка условия через заданный интервал времени. Сенсор «просыпается», проверяет условие и, если оно не выполнено, снова засыпает. Интервал задаётся параметром poke_interval. Такой подход прост, но может потреблять ресурсы, если сенсоров много. Поэтому polling нужно использовать аккуратно.
Что такое polling и periodic polling?
Polling — это подход, при котором клиент сам регулярно запрашивает сервер на наличие обновлений. Periodic polling — частный случай polling, когда запросы отправляются с фиксированным интервалом. Клиент не ждёт уведомлений от сервера, а сам проверяет, изменились ли данные. Такой подход проще WebSocket, но менее эффективен.
Когда polling может быть предпочтительнее WebSocket?
Какие проблемы могут возникнуть при polling?
Как обрабатывать падение сервера при polling?
Чем setInterval хуже setTimeout для polling?
Почему важно учитывать время ответа сервера при polling?
Рейтинг:
4
Сложность:
6
Polling предпочтительнее WebSocket, когда обновления редкие и не требуют мгновенной доставки. Он проще в реализации, легче масштабируется и лучше проходит через прокси и корпоративные сети. Если допустима задержка в несколько секунд, polling часто оказывается более практичным. В таких случаях WebSocket будет избыточным.
Рейтинг:
5
Сложность:
6
Polling создаёт лишние запросы к серверу, даже когда данные не меняются. Это увеличивает нагрузку на backend и сеть. Между фактическим изменением данных и их отображением возникает задержка. Также усложняется обработка ошибок и контроль количества одновременных запросов.
Рейтинг:
4
Сложность:
7
При падении сервера polling нельзя продолжать “в лоб” с тем же интервалом. Нужно обрабатывать ошибки и менять поведение клиента: замедлять запросы, делать retry с задержкой и информировать пользователя. Часто используют exponential backoff, чтобы не усугублять нагрузку. После восстановления сервера polling возвращается к нормальному режиму.
Рейтинг:
4
Сложность:
5
setInterval запускает обработчик по расписанию, даже если предыдущий запрос ещё не закончился, из-за чего появляются параллельные запросы и лишняя нагрузка. Интервалы также “плывут” (drift): если обработчик выполняется долго, фактические моменты запуска смещаются. setTimeout удобнее для polling, потому что позволяет запускать следующий запрос после завершения предыдущего и гибко менять задержку (например, при ошибках увеличить).
Рейтинг:
3
Сложность:
6
Если время ответа сервера большое, то частый polling приводит к параллельным запросам, очередям и росту нагрузки. Это может вызвать замедление приложения, лишний трафик и даже 429/5xx из-за перегруза. Правильный polling учитывает latency: следующий запрос отправляют после завершения предыдущего и/или увеличивают интервал. Иногда лучше заменить polling на WebSocket/SSE, если нужны частые обновления.
Рейтинг:
2
Сложность:
6
Рейтинг:
5
Сложность:
7
Рейтинг:
5
Сложность:
7
Рейтинг:
4
Сложность:
7
Рейтинг:
5
Сложность:
5
