Альтернативы Centrifugo для Laravel: Reverb, Pusher, Ably, Socket.IO, SSE и polling

• Polling — если обновления редкие и задержка не критична.
  
• SSE — если нужен простой поток событий только от сервера к клиенту.
  
• Laravel Reverb — если проект Laravel-first и нужна нативная интеграция с Broadcasting.
  
• Pusher — если нужен быстрый managed real-time без своей инфраструктуры.
  
• Ably — если нужен managed real-time с сильной платформой и SLA.
  
• Socket.IO — если realtime-слой уже живёт в Node.js или нужна богатая двусторонняя интерактивность.
  
• Centrifugo — если нужен отдельный self-hosted realtime gateway, независимый от Laravel.

• доставлять уведомления пользователю;
  
• обновлять статусы заказов, платежей или задач;
  
• показывать live-дашборд;
  
• обновлять stream-виджеты;
  
• поддерживать чат;
  
• показывать presence: кто онлайн;
  
• обновлять админские панели без перезагрузки;
  
• доставлять события в интерфейс с минимальной задержкой;
  
• восстанавливать состояние после потери соединения.

• Есть ли новые уведомления?
  
• Изменился ли статус заказа?
  
• Готов ли отчёт?

setInterval(async function () {
    const response = await fetch('/api/notifications/count', {
        credentials: 'include',
        headers: {
            Accept: 'application/json',
        },
    });
    const data = await response.json();
    updateNotificationsCounter(data.count);
}, 10000);

• данные обновляются редко;
  
• задержка 5–30 секунд допустима;
  
• пользователей немного;
  
• нет сложных каналов и подписок;
  
• real-time не является ключевой частью продукта;
  
• команда не хочет поддерживать отдельный WebSocket-сервис.

• статус генерации отчёта;
  
• редкое обновление счётчика;
  
• проверка готовности файла;
  
• простая админская панель;
  
• личный кабинет без критичных live-событий.

• очень просто реализовать;
  
• понятно любому backend-разработчику;
  
• легко дебажить;
  
• не нужен WebSocket;
  
• не нужен отдельный сервис;
  
• работает почти в любой инфраструктуре;
  
• нет проблем с token refresh WebSocket-соединения.

• лишняя нагрузка при большом количестве клиентов;
  
• есть задержка обновления;
  
• плохо подходит для частых событий;
  
• не подходит для чатов и live-интерфейсов;
  
• много пустых запросов, если данные редко меняются.

• Frontend → HTTP request → Backend ждёт событие
  
• Backend → response при событии или timeout
  
• Frontend → сразу новый request

• WebSocket недоступен или нежелателен;
  
• нужны более быстрые обновления, чем polling;
  
• событий немного;
  
• инфраструктура плохо поддерживает WebSocket;
  
• нужен временный компромисс.

• работает поверх HTTP;
  
• меньше пустых запросов, чем у polling;
  
• может быть проще WebSocket в старой инфраструктуре.

• сложнее обычного polling;
  
• хуже WebSocket для частых событий;
  
• держит открытые HTTP-соединения;
  
• требует аккуратной настройки timeout;
  
• плохо масштабируется без продуманной архитектуры.

const events = new EventSource('/api/events');
events.addEventListener('message', function (event) {
    const payload = JSON.parse(event.data);
    handleEvent(payload);
});

• нужны события только server → client;
  
• клиенту не нужно отправлять сообщения по тому же соединению;
  
• сценарии простые;
  
• нужно обновлять статусы, прогресс, уведомления, live-ленту;
  
• WebSocket выглядит избыточно.

• прогресс выполнения задачи;
  
• обновление статуса импорта;
  
• уведомления;
  
• live feed;
  
• простые dashboard-обновления.

• проще WebSocket;
  
• работает поверх HTTP;
  
• нативно поддерживается браузером;
  
• хорошо подходит для server-to-client событий;
  
• понятная модель доставки.

• однонаправленная связь;
  
• не подходит для полноценного чата;
  
• сложнее делать presence и приватные подписки;
  
• нужны корректные настройки proxy и timeout;
  
• не всегда удобно масштабировать в PHP-only окружении.

• проект полностью или почти полностью на Laravel;
  
• нужна нативная интеграция с Laravel Broadcasting;
  
• команда использует Laravel Echo;
  
• нет отдельного multi-language realtime слоя;
  
• нужен self-hosted WebSocket без SaaS;
  
• нагрузка умеренная или предсказуемая;
  
• команда хочет меньше интеграционного кода.

• официальное Laravel-решение;
  
• хорошая интеграция с Broadcasting;
  
• удобный developer experience;
  
• понятно Laravel-разработчикам;
  
• не нужен внешний SaaS;
  
• не нужен отдельный Go/Node realtime service;
  
• можно быстрее стартовать внутри Laravel-проекта.

• привязка к Laravel-экосистеме;
  
• хуже подходит как универсальный realtime gateway для разных языков;
  
• эксплуатационно это всё равно long-running процесс;
  
• нужны supervisor, мониторинг, логи, деплой;
  
• для сложных multi-service сценариев может быть менее гибким, чем Centrifugo.

• личный кабинет Laravel SaaS;
  
• уведомления;
  
• статусы заказов;
  
• простые админские панели;
  
• умеренный real-time;
  
• одна Laravel-команда;
  
• один основной backend.

• несколько backend-сервисов на разных языках;
  
• real-time должен быть отдельным инфраструктурным слоем;
  
• много независимых источников событий;
  
• нужна языковая независимость;
  
• сложная модель каналов вне Laravel.

• нужно быстро запустить real-time;
  
• нет желания администрировать WebSocket-сервер;
  
• команда маленькая;
  
• нагрузка умеренная;
  
• бюджет позволяет SaaS;
  
• SLA и скорость запуска важнее полного контроля инфраструктуры.

• быстрый старт;
  
• минимум эксплуатации;
  
• хорошая интеграция с Laravel Echo;
  
• не нужно думать о WebSocket-серверах;
  
• не нужно отдельно настраивать scaling и monitoring сервера;
  
• удобно для MVP и коммерческих продуктов с бюджетом.

• стоимость растёт с нагрузкой;
  
• vendor lock-in;
  
• ограничения тарифов;
  
• данные и инфраструктура уходят во внешний сервис;
  
• меньше контроля над внутренней механикой доставки.

• нужен managed real-time;
  
• важны SLA и глобальная доставка;
  
• нужны дополнительные возможности платформы;
  
• нет желания поддерживать self-hosted WebSocket;
  
• проект коммерческий;
  
• бюджет на инфраструктуру нормальный.

• сильная managed-инфраструктура;
  
• меньше operational burden;
  
• подходит для распределённых сценариев;
  
• есть Laravel-интеграция;
  
• не нужно держать свой WebSocket-сервер.

• стоимость;
  
• vendor lock-in;
  
• зависимость от внешнего провайдера;
  
• может быть избыточен для простых проектов;
  
• часть решений придётся подстраивать под платформу.

• основной realtime gateway уже на Node.js;
  
• команда уверенно работает с Node.js;
  
• нужна богатая двусторонняя интерактивность;
  
• нужны комнаты, события, кастомная server-side realtime логика;
  
• делается чат, multiplayer, collaborative UI, live-интерфейс.

• зрелая экосистема;
  
• много примеров;
  
• удобная событийная модель;
  
• есть комнаты;
  
• есть fallback-механизмы;
  
• хорош для чатов и интерактивных приложений.

• добавляет Node.js-инфраструктуру рядом с Laravel;
  
• не является Laravel-native решением;
  
• нужна отдельная интеграция авторизации;
  
• нужны отдельный деплой, логи, мониторинг;
  
• может быть избыточен, если нужно просто доставлять backend events в UI.

• нужен отдельный realtime слой;
  
• Laravel — не единственный backend;
  
• события публикуют разные сервисы;
  
• нужен self-hosted вариант;
  
• не хочется платить SaaS по мере роста нагрузки;
  
• нужны каналы, приватные подписки, presence, history;
  
• важна языковая независимость;
  
• real-time должен быть инфраструктурным компонентом, а не частью одного Laravel-приложения.

• open-source;
  
• language-agnostic;
  
• self-hosted;
  
• заточен под real-time messaging;
  
• поддерживает разные транспорты;
  
• хорошо подходит как отдельный realtime gateway;
  
• может обслуживать несколько backend-сервисов;
  
• отделяет Laravel business logic от WebSocket-соединений.

• ещё один сервис в инфраструктуре;
  
• нужны деплой, конфигурация, мониторинг, логи;
  
• интеграция с Laravel менее “родная”, чем у Reverb;
  
• команде нужно понимать JWT, каналы, publish API, token refresh;
  
• ошибки эксплуатации становятся частью real-time системы.

• есть несколько backend-сервисов;
  
• часть системы не на Laravel;
  
• real-time должен пережить смену backend-фреймворка;
  
• нужен самостоятельный gateway;
  
• команда готова эксплуатировать отдельный сервис;
  
• нагрузка и каналы могут расти независимо от Laravel.

• проект маленький;
  
• событий мало;
  
• вся система — один Laravel backend;
  
• команда не хочет держать отдельный сервис;
  
• реального real-time почти нет;
  
• обновление раз в 10 секунд достаточно.

•  Зачем нужен WebSocket в Laravel-приложении
  
•  Архитектура Laravel + Centrifugo: роли backend, WebSocket-сервера и frontend
  
•  Каналы и авторизация в Centrifugo
  
•  Публикация событий Laravel в Centrifugo
  
•  Frontend и эксплуатация Centrifugo JS client
  
•  Альтернативы Centrifugo: Laravel Reverb, Pusher, Ably,Socket.IO, SSE и polling

• Centrifugo — официальная документация
  Базовая документация по Centrifugo: сервер, каналы, подключения, публикации и основные сценарии real-time messaging.
  
• Centrifuge JS client
  JavaScript-клиент для подключения браузера, Node.js или React Native к Centrifugo/Centrifuge-based серверу.
  
• Centrifugo Client SDK specification
  Описание поведения клиентских SDK: подключение, подписки, reconnect, token refresh и обработка состояний клиента.
  
• Laravel Broadcasting
  Официальная документация Laravel по broadcasting, Laravel Echo, channels, events и broadcast drivers.
  
• Laravel Reverb
  Официальная документация Laravel Reverb — first-party WebSocket-сервера для Laravel-приложений.
  
• Laravel Queues
  Документация по очередям Laravel: jobs, workers, retries, failed jobs и обработка фоновых задач.
  
• Laravel Events
  Документация по событиям Laravel: events, listeners, subscribers и асинхронная обработка.
  
• Laravel Echo
  Клиентская библиотека Laravel для подписки на broadcast-события во frontend-приложениях.
  
• Pusher Channels
  Документация managed real-time сервиса Pusher Channels.
  
• Ably Pub/Sub Channels
  Документация Ably по каналам, Pub/Sub и real-time messaging.
  
• Socket.IO
  Документация Socket.IO — библиотеки для bidirectional event-based communication между клиентом и сервером.
  
• MDN WebSocket API
  Базовое описание WebSocket API в браузере.
  
• MDN EventSource / Server-Sent Events
  Документация по Server-Sent Events и интерфейсу EventSource.