Real-time на сайте с Laravel и Centrifugo: зачем нужен WebSocket

[Xbolt]

Очень странно читать такое после 15 лет как появился websocket. Описаны элементарные вещи. Которые должны быть понятны с первого написания первого кода.

[maxyc_webber]

Справедливое замечание, если смотреть на статью как на материал для людей, которые давно проектируют real-time системы.

Но статья не про "открытие WebSocket в 2026 году", а про базовую инженерную рамку для тех, кто в проектах всё ещё путает WebSocket, broadcasting, очереди, события и ответственность frontend/backend.

На практике элементарные вещи часто ломаются именно потому, что их считают очевидными: публикуют события из контроллеров, отправляют огромный payload, не думают про reconnect, не проверяют права на каналы, не восстанавливают состояние через HTTP.

Поэтому да, материал базовый. Но он специально такой: не для того, чтобы удивить опытных инженеров.

[Xbolt]

И я о том же, что есть необходимость такой статьи.

[Valsha]

Разве для Laravel не более гармонично было бы использовать https://reverb.laravel.com/ ?

[maxyc_webber]

Да, для Laravel-first проекта Reverb действительно выглядит более гармоничным и естественным вариантом. Это нативное решение Laravel, и во многих проектах его будет достаточно.

В моём случае Centrifugo появился не потому, что Reverb хуже, а потому что так исторически сложилось на проекте, с которым я работаю: real-time слой там начали строить ещё до появления Reverb. Поэтому Centrifugo уже был частью архитектуры и инфраструктуры.

В этой серии я разбираю real-time шире: не только “как подключить WebSocket в Laravel”, а как проектировать каналы, токены, очереди, публикацию событий, frontend, reconnect, эксплуатацию и выбор подходящего инструмента.

Про альтернативы как раз будет отдельная статья.