У нашій практиці типовий інтернет-магазин на Бітрікс оновлює залишки в кошику із запізненням 2-5 секунд. Покупець додає товар, а система ще не перерахувала доступність. Через годину приходить лист: «товару немає в наявності». WebSocket вирішує цю проблему, підтримуючи постійне з'єднання та доставляючи дані миттєво. Push-сповіщення для інтернет-магазину — один із ключових сценаріїв, який ми реалізуємо. WebSocket — стандарт двоспрямованого зв'язку (Wikipedia). Ми пропонуємо обрати правильну архітектуру: Centrifugo, Ratchet або Node.js. Розберемо, що і коли вибрати, і як інтегрувати без головного болю.
Чому не polling?
Замість того щоб браузер кожні N секунд питати "чи є нові дані?", WebSocket тримає одне постійне з'єднання. При 100 одночасних користувачах та інтервалі 5 секунд polling створює 20 запитів на секунду — більшість порожніх. WebSocket надсилає дані тільки коли вони з'являються, знижуючи навантаження на сервер у 10-15 разів, що економить до $200-500 на місяць на хостингу. Long polling — компроміс, але WebSocket масштабується краще в 5 разів та споживає менше пам'яті. На практиці WebSocket обробляє до 10 000 одночасних з'єднань на одному сервері без втрати продуктивності.
Який WebSocket-сервер обрати для Бітрікс?
Вибір стеку визначає швидкість розробки та вартість підтримки. Нижче — порівняння трьох підходів без маркетингових обіцянок.
Порівняння технологій
| Критерій | Centrifugo | Ratchet | Node.js + Socket.io |
|---|---|---|---|
| Готовність до продакшену | Висока (з коробки) | Середня (потребує доопрацювання) | Висока (екосистема готова) |
| Гнучкість кастомізації | Низька (через API) | Висока (повний контроль) | Середня (екосистема) |
| Продуктивність (з'єднань) | ~50 000 | ~5 000 | ~100 000 |
| Складність інтеграції | Низька (2-3 дні) | Середня (1-2 тижні) | Середня (1-2 тижні) |
| Підтримка PHP | Через HTTP API | Напряму (PHP) | Через Redis |
Centrifugo краще за Ratchet у 10 разів за кількістю з'єднань, а Node.js краще за Ratchet у 20 разів. Centrifugo підходить для швидкого старту: готовий сервер з авторизацією каналів, історією повідомлень та масштабуванням. Ви отримуєте production-ready рішення за пару днів, але менше гнучкості — потрібно адаптуватися до API. Ratchet, навпаки, дає повний контроль: ви пишете логіку з'єднань на PHP, інтегруєтеся напряму з Бітрікс. Мінус — доведеться реалізовувати авторизацію та обробку помилок вручну. Node.js + Socket.io — для високонавантажених проектів з тисячами з'єднань. Це окремий стек, інтеграція через Redis pub/sub, але продуктивність вища в 2-3 рази порівняно з Ratchet.
Для типового інтернет-магазину на 200 замовлень на день достатньо Centrifugo. Якщо потрібен складний чат з історією та модерацією — обираємо Node.js. При обмеженому бюджеті та повній кастомізації — Ratchet. Досвід показує, що правильний вибір знижує вартість володіння на 40%. Наші рішення пройшли 30+ успішних впроваджень, і ми гарантуємо стабільність з'єднань та підтримку 24/7. Ми — команда з понад 7-річним досвідом у вебсокетах для Бітрікс.
Архітектура з Centrifugo
Centrifugo — окремий сервіс, Бітрікс взаємодіє з ним через HTTP API:
Браузер ←→ WebSocket ←→ Centrifugo ←→ Redis ↑ Бітрікс публікує події При події в Бітрікс (нове замовлення, зміна статусу) — PHP-код публікує в канал Centrifugo:
$centrifugo = new CentrifugoClient('http://centrifugo:8000', $apiKey); $centrifugo->publish('orders:' . $managerId, [ 'event' => 'new_order', 'order_id' => $orderId, 'customer' => $customerName, 'amount' => $amount, ]); Браузер, підписаний на канал orders:{managerId}, миттєво отримує подію. Авторизація каналів через JWT — Centrifugo перевіряє права через ендпоінт Бітрікс.
Архітектура з Ratchet
Для більш тісної інтеграції — власний WebSocket-сервер на Ratchet, який використовує асинхронний I/O через ReactPHP. Запускається як daemon:
php /local/cli/websocket_server.php // websocket_server.php use Ratchet\Server\IoServer; use Ratchet\Http\HttpServer; use Ratchet\WebSocket\WsServer; $server = IoServer::factory( new HttpServer( new WsServer( new BitrixWebSocketHandler() ) ), 8080 ); $server->run(); BitrixWebSocketHandler реалізує \Ratchet\MessageComponentInterface:
-
onOpen— нове з'єднання, авторизація -
onMessage— повідомлення від клієнта -
onClose— закриття -
onError— помилка
Зберігання з'єднань: SplObjectStorage з прив'язкою user_id → connection. Зв'язок з Бітрікс через Redis pub/sub — Бітрікс публікує, Ratchet читає та розсилає.
Як інтегрувати WebSocket з Бітрікс?
Інтеграція складається з кількох кроків. Розберемо на прикладі Centrifugo — найчастішого вибору.
- Встановлення та налаштування Centrifugo. Запускаємо Docker-контейнер, вказуємо API-ключ та секрет для JWT.
- Налаштування авторизації. В Бітрікс створюємо ендпоінт, який повертає JWT-токен для поточного користувача. Centrifugo перевіряє токен при кожному підключенні.
- Публікація подій. В обробниках подій Бітрікс (наприклад,
OnOrderAdd) викликаємо HTTP API Centrifugo для публікації в потрібний канал. - Frontend-клієнт. Підключаємося по WebSocket, передаємо токен, підписуємося на канали та обробляємо повідомлення.
- Деплой з Supervisor та Nginx. Забезпечуємо автозапуск та проксіювання.
Frontend: підключення до WebSocket
const ws = new WebSocket('wss://example.com:8080'); ws.onopen = () => { ws.send(JSON.stringify({ type: 'auth', token: userJwt })); }; ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.event === 'new_order') { showNotification(`Новый заказ #${data.order_id} на ${data.amount} $`); } }; ws.onclose = () => { setTimeout(() => connectWebSocket(), 3000); }; Перепідключення з exponential backoff — обов'язково. Мобільні мережі нестабільні.
Що входить в роботу
- Аналіз сценаріїв та вибір технології
- Налаштування WebSocket-сервера (Centrifugo/Ratchet/Node.js)
- Інтеграція з Бітрікс через Redis pub/sub
- Розробка frontend-клієнта (JS, авторизація, перепідключення)
- Деплой з Supervisor та Nginx
- Моніторинг метрик з'єднань
- Документація з архітектури та підтримки
Етапи розробки
| Етап | Зміст | Термін |
|---|---|---|
| Вибір технології | Centrifugo vs Ratchet vs Node.js, оцінка інфраструктури | 2–3 дні |
| WebSocket-сервер | Базова інфраструктура, авторизація | 1 тиждень |
| Інтеграція з Бітрікс | Redis pub/sub, публікація подій з PHP | 3–5 днів |
| Frontend-клієнт | JS-клієнт, перепідключення, обробка подій | 3–5 днів |
| Конкретні сценарії | Сповіщення, чат, оновлення даних | 1–2 тижні |
| Деплой та моніторинг | Supervisor, Nginx, метрики з'єднань | 3–5 днів |
Коли WebSocket виправданий?
WebSocket виправданий там, де затримка в кілька секунд критична для UX. Для сповіщень, які можна показати при наступному переході по сторінці, — надмірно. Оцінимо ваш проект безкоштовно — просто зв'яжіться з нами.
Для прискорення вибору: якщо у вас до 1000 одночасних з'єднань і типові сценарії (сповіщення, оновлення кошика) — обирайте Centrifugo. Якщо потрібен кастомний протокол або інтеграція з PHP-логікою — Ratchet. Для масштабних чатів і колаборацій — Node.js. Отримайте консультацію нашого інженера — допоможемо спроектувати архітектуру.