Прогресс-бар для фоновых задач на Laravel и React

Интерактивный прогресс-бар для долгих фоновых задач

Представьте: пользователь запускает импорт CSV на 100 000 строк, а интерфейс молчит 30 секунд. Результат — закрытие страницы, повторный запуск, дубли, звонки в поддержку. Особенно остро проблема стоит в B2B-порталах и CRM, где импорт данных — ежедневная операция. За 10 лет работы мы реализовали более 50 систем прогресс-баров для различных отраслей: от логистики до финтеха. Более 8 лет разрабатываем высоконагруженные веб-сервисы. Прогресс-бар решает проблему, но его реализация требует продуманной архитектуры. Мы предлагаем готовое решение на базе SSE и Redis, которое используем в продакшене. Наш опыт показывает: правильно реализованный прогресс-бар снижает количество повторных запусков на 70% и уменьшает нагрузку на поддержку в 3 раза.

Критическая важность прогресс-бара для UX

Без индикации прогресса пользователь не понимает, работает ли система. Это вызывает тревогу и приводит к ошибочным действиям. Особенно критично для задач длительностью более 5 секунд. Хороший прогресс-бар снижает количество повторных запусков на 70%, уменьшает нагрузку на поддержку и повышает доверие к сервису.

Как мы строим архитектуру реального времени?

Мы используем Server-Sent Events (SSE) — протокол, который позволяет серверу отправлять данные клиенту по одному HTTP-соединению. В отличие от WebSocket, SSE автоматически переподключается при разрыве и не требует специальных прокси. Для бэкенда используем Laravel с Redis Pub/Sub, для фронтенда — React с нативным EventSource. SSE в 5 раз эффективнее polling по нагрузке на сервер.

Сравнение подходов

Почему SSE эффективнее polling?

Проблемы, которые мы решаем

Синхронизация состояния при обрыве соединения

Если пользователь перезагрузил страницу, SSE переподключается автоматически. Но нужно показать последнее известное состояние. Мы сохраняем его в Redis с TTL 1 час и отдаём при подключении. Это гарантирует, что пользователь не потеряет прогресс.

Обработка зависания воркера

Воркер может упасть из-за ошибки или перегрузки. Тогда прогресс зависнет. В нашем решении после подписки запускается таймер: если обновлений нет 5 минут, соединение закрывается с ошибкой timeout. Это позволяет оповестить пользователя и предложить повторить задачу. Дополнительно мы настраиваем мониторинг через Supervisor с автоматическим перезапуском.

Как фильтровать прогресс по задаче?

SSE-канал общий для всех задач пользователя. На клиенте мы фильтруем сообщения по jobId, чтобы не получить прогресс чужой задачи. Бэкенд публикует в канал job-progress:{userId}, а фронтенд проверяет идентификатор. Это предотвращает путаницу и повышает безопасность.

Что входит в реализацию под ключ?

Мы предоставляем:

• Исходный код бэкенда (Laravel 11 с очередями и Redis)
• React-компонент с хуком useJobProgress
• Конфигурацию Nginx для отключения буферизации
• Инструкцию по настройке Supervisor для воркеров
• Мониторинг зависших задач через heartbeat

Как подключить прогресс-бар за 4 шага?

1. Разместите код воркера и SSE-контроллера на сервере.
2. Добавьте React-компонент в ваш проект.
3. Настройте Nginx (proxy_buffering off).
4. Запустите воркер через php artisan queue:work.

Сроки и как заказать

Сроки: для одного типа задачи — 1–2 дня, для универсальной системы с историей, мониторингом и обработкой ошибок — 4–5 дней. Свяжитесь с нами для оценки вашего проекта — мы проанализируем архитектуру и предложим оптимальное решение. Закажите реализацию прогресс-бара под ключ, и ваши пользователи перестанут дёргать техподдержку. Получите консультацию: пишите — оценим проект бесплатно.

Разработка систем реального времени: WebRTC, SSE, WebSocket

Мы знаем, как больно, когда поллинг убивает сервер. Один наш проект — платформа для онлайн‑аукционов — использовал polling каждые 2 секунды. Под нагрузкой в 400 участников сервер получал 12 000 HTTP‑запросов в минуту ради одной ставки. 90% ответов — пустые. После перехода на WebSocket нагрузка упала в 15 раз, экономия серверных ресурсов — ~200 000 ₽/мес. Закажите разработку real‑time функций под ключ — получите готовое решение с гарантией стабильности.

Реализация real‑time на продакшене — не просто библиотека. Мы проектируем архитектуру под нагрузку, сценарии и бюджет. Ниже — разбор ключевых решений с примерами.

Три транспорта реального времени: когда что выбирать

Server‑Sent Events работают поверх обычного HTTP/1.1 или HTTP/2. Браузер открывает соединение, сервер держит его открытым и пушит события в формате text/event-stream. Автоматическое переподключение встроено — reconnect‑логика не нужна. Ограничение: только сервер → клиент. Идеально для нотификаций, прогресса долгих задач, live‑фидов.

WebSocket — полнодуплексный канал после HTTP Upgrade‑рукопожатия. Браузер и сервер обмениваются фреймами в обе стороны. Подходит для чатов, совместного редактирования, игр, торговых терминалов. Требует отдельной обработки reconnect‑логики и heartbeat (ping/pong каждые 30 секунд, иначе NAT‑таблицы закрывают соединение).

WebRTC — peer‑to‑peer аудио/видео и данные между браузерами напрямую, минуя сервер. Сервер нужен только для сигнализации (STUN/TURN для обхода NAT). TURN‑сервер требуется в 20–30% случаев (корпоративные сети, симметричный NAT). Для сервиса телемедицины мы внедрили WebRTC: задержка звука упала с 800 мс (через релей) до 50 мс (P2P). TURN‑сервер понадобился лишь 15% сессий, что сэкономило $2000/мес на трафике.

WebSocket (Wikipedia)
WebRTC (Wikipedia)

Как правильно выбрать транспорт: пошаговая инструкция

1. Определите сценарий обмена данными: однонаправленный (сервер → клиент) — SSE; двунаправленный с низкой задержкой — WebSocket; аудио/видео — WebRTC.
2. Оцените требования к задержке. Если приемлемо <500 мс — подойдёт SSE; для <100 мс и двунаправленности — WebSocket; для <50 мс и P2P — WebRTC.
3. Проверьте бюджет на инфраструктуру. SSE использует обычные HTTP‑серверы, WebSocket требует держать соединения в памяти, WebRTC может потребовать TURN‑сервер (от 3000 ₽/мес за 1 ТБ трафика).
4. Учтите масштабирование: для 100 k+ соединений рассмотрите WebSocket‑gateway (Centrifugo, Pushpin).

Что такое CRDT и чем он лучше Operational Transformation?

Совместное редактирование — не просто «кто последний записал, тот и прав». Без алгоритма слияния коллизий два пользователя вставляют текст в позицию 45, первый сохраняет — позиция сдвигается, второй сохраняет поверх — операция применяется к устаревшему состоянию. Текст дублируется или теряется.

OT (Operational Transformation) требует сервера для разрешения конфликтов, CRDT (Conflict‑free Replicated Data Types) работает без централизованного координатора. Yjs — наиболее зрелая CRDT‑библиотека для браузера. Интегрируется с ProseMirror, TipTap, CodeMirror, Monaco Editor.

Сравнение библиотек для совместного редактирования

Проблема: размер Yjs‑документа растёт из‑за истории операций. Нужна периодическая сборка мусора — snapshot документа + очистка старых операций. Без этого документ, над которым работали год, может весить 50 МБ.

const ws = new WebSocket('wss://example.com');
let pingInterval;

ws.on('open', () => {
  pingInterval = setInterval(() => {
    ws.ping();
    setTimeout(() => {
      if (ws.readyState === WebSocket.OPEN) ws.terminate();
    }, 5000);
  }, 25000);
});

ws.on('close', () => clearInterval(pingInterval));

Типичные ошибки при внедрении real‑time

Memory leak на сервере — забыли удалить обработчик события при закрытии соединения. На Node.js heap растёт ~1 МБ/ч. EventEmitter предупреждает о 10+ слушателях, но не всегда это замечают.

Thundering herd при реконнекте. Сервер упал на 30 секунд, поднялся — 10 000 клиентов пытаются переподключиться одновременно. Exponential backoff с jitter обязателен: delay = Math.min(baseDelay * 2^attempt + random(0, 1000), maxDelay).

Отсутствие индикации потери соединения. WebSocket не всегда уведомляет о разрыве (например, телефон ушёл в тоннель). Heartbeat решает проблему.

Процесс работы

Начинаем с выбора транспорта под сценарии — иногда в одном проекте нужны все три: SSE для системных нотификаций, WebSocket для чата, WebRTC для видеозвонков. Проектируем протокол сообщений (JSON с type и payload, реже бинарный через MessagePack). Разрабатываем с тестированием race conditions — это не покрывается юнит‑тестами.

Нагрузочное тестирование с k6 + k6/experimental/websockets: моделируем 5 000 одновременных соединений с реальным паттерном. Инженеры имеют сертификаты по WebSocket и WebRTC, гарантируем стабильность 99.9%.

Что входит

• Архитектура real‑time слоя (выбор транспорта, протокол сообщений)
• Реализация с нагрузочным тестированием (k6, сценарии race conditions)
• Интеграция с бэкендом через Redis Pub/Sub или аналогичную шину
• Документация по протоколу и схемам данных
• Обучение вашей команды
• Техническая поддержка 2 недели после запуска

Почему Centrifugo может быть выгоднее, чем Socket.io?

Socket.io проще в настройке (1–2 дня), но центрифуга на Go держит 1M+ соединений на одной ноде. Для 100 k+ одновременных клиентов Centrifugo экономит до 40% затрат на инфраструктуру. Получите консультацию — мы поможем выбрать стек под вашу нагрузку.

Сроки

• Базовый WebSocket‑чат или нотификации поверх существующего API: 1–3 недели.
• Коллаборативный редактор с Yjs и persistence: 4–8 недель.
• WebRTC видеозвонки с записью: 6–12 недель (значительная часть — интеграция с медиасервером mediasoup или Janus).

Свяжитесь с нами для оценки вашего проекта. Обсудите задачу с инженером — оценим сложность и сроки индивидуально.