> Какие альтернативы есть для фронтенда вместо постоянных запросов для проверки статуса задачи (Python)

Короткий ответ

Основная альтернатива постоянным запросам (polling) - push-модель: WebSocket, Server-Sent Events (SSE) или long polling. Для фоновых задач также используют webhooks и очереди сообщений с уведомлениями. Выбор зависит от требований: WebSocket подходит для двустороннего общения, SSE - для однонаправленных уведомлений, webhook - когда сервер может сам инициировать запрос. В Python-бэкенде часто используют FastAPI с WebSocket или Redis pub/sub для масштабирования.

Подробное объяснение

Постоянные запросы (polling) создают избыточную нагрузку на сервер и сеть, особенно при большом количестве клиентов. Альтернативы:

1. WebSocket - полноценный двусторонний канал. Клиент подписывается на обновления статуса, сервер отправляет события по мере готовности. Требует поддержки на инфраструктурном уровне (балансировщики, прокси).

2. Server-Sent Events (SSE) - однонаправленный поток от сервера к клиенту. Проще WebSocket, работает поверх обычного HTTP, автоматически переподключается. Идеален для уведомлений о статусе задач.

3. Long polling - клиент делает запрос, сервер держит соединение открытым до появления результата или таймаута. Компромисс между polling и push, но всё ещё создаёт нагрузку.

4. Webhook - сервер сам отправляет POST-запрос на указанный URL клиента, когда задача завершена. Требует публичного endpoint у клиента и механизма доставки (retry, idempotency).

5. Очереди сообщений (RabbitMQ, Redis Streams) - клиент подписывается на канал, бэкенд публикует события. Хорошо масштабируется, но добавляет инфраструктурную сложность.

Для Python-бэкенда типичная связка: FastAPI + WebSocket для реального времени, Celery + Redis для фоновых задач, и уведомление через WebSocket/SSE после завершения задачи.

На практике

Для фоновых задач в Python (Celery, RQ) обычно используют комбинацию:

• Клиент отправляет задачу, получает task_id.
• Бэкенд запускает задачу воркером.
• По завершении воркер публикует событие в Redis pub/sub или отправляет через WebSocket.
• Клиент подписан на канал и получает уведомление.

Если клиент - браузер, WebSocket или SSE - стандартный выбор. Если клиент - другой сервер, webhook часто проще. Для мобильных приложений используют push-уведомления (FCM/APNs), которые тоже являются push-моделью.

Важно учитывать: WebSocket требует поддержки на уровне балансировщика (sticky sessions или Redis pub/sub для горизонтального масштабирования). SSE проще, но не поддерживает двустороннюю связь.

Пример кода

PYTHON
# FastAPI + WebSocket + Celery
from fastapi import FastAPI, WebSocket
from celery import Celery
import redis

app = FastAPI()
celery = Celery('tasks', broker='redis://localhost:6379/0')
redis_client = redis.Redis()

@celery.task
def long_task(task_id: str):
    # имитация работы
    time.sleep(10)
    # публикуем результат
    redis_client.publish(f'task:{task_id}', 'completed')

@app.websocket('/ws/{task_id}')
async def websocket_endpoint(websocket: WebSocket, task_id: str):
    await websocket.accept()
    pubsub = redis_client.pubsub()
    pubsub.subscribe(f'task:{task_id}')
    try:
        for message in pubsub.listen():
            if message['type'] == 'message':
                await websocket.send_text(message['data'])
                break
    finally:
        pubsub.unsubscribe()
        await websocket.close()

Как отвечать на собеседовании

Начни с краткого перечисления альтернатив, затем уточни, какой контекст имеется в виду: браузерный клиент, мобильное приложение или сервер-сервер. Покажи понимание trade-off: WebSocket сложнее инфраструктурно, но даёт двустороннюю связь; SSE проще, но однонаправленный; webhook требует публичного endpoint. Упомяни, что выбор зависит от требований к реальному времени, количеству клиентов и инфраструктуре. Для Python-бэкенда обязательно упомяни связку с Celery и Redis pub/sub.

Что проверяет интервьюер

• Понимание разницы между push и pull моделями.
• Знание конкретных технологий и их ограничений.
• Умение оценивать trade-off под конкретные требования.
• Понимание, как это встраивается в типичный Python-стек (Celery, Redis, FastAPI).
• Осведомлённость о проблемах масштабирования (sticky sessions, pub/sub).

Типичные ошибки

• Предлагать WebSocket как универсальное решение, не учитывая сложность инфраструктуры.
• Путать SSE и WebSocket, не понимая, что SSE однонаправленный.
• Забывать про webhook как вариант для сервер-серверных интеграций.
• Не упоминать про проблемы с балансировщиками и необходимость sticky sessions для WebSocket.
• Предлагать long polling как современное решение, не отмечая его недостатки.
• Не учитывать, что для мобильных клиентов WebSocket может быть не лучшим выбором из-за энергопотребления.