Інтеграція Ably для real-time даних на сайті

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Інтеграція Ably для real-time даних на сайті
Простий
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    958
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    932
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    949

Будь-яка затримка у відображенні біржових котирувань може коштувати клієнту великої суми. У багатокористувацькому редакторі розсинхронізація станів призводить до втрачених правок. Ably забезпечує затримку менше 50 мс і гарантовану доставку з SLA 99.999% для enterprise-планів. Ми виконали 50+ інтеграцій Ably для fintech, edtech та collaboration-продуктів, включаючи проекти з мільйонами одночасних користувачів. У цій статті розбираємо, як налаштувати pub/sub, token auth і уникнути типових помилок, спираючись на реальний досвід.

Чому Ably?

Ably — managed real-time платформа з глобальною інфраструктурою (180+ PoP), підтримкою pub/sub, presence та історії повідомлень. На відміну від Pusher, Ably надає вбудований WebSocket streams та збереження історії до 30 днів. WebSocket — протокол повнодуплексного зв'язку поверх TCP. Ми вибираємо Ably для проектів, де критичні 99.999% uptime та масштабування до мільйона одночасних з'єднань. Порівняно з Socket.IO, Ably пропонує в 10 разів меншу затримку при глобальній доставці та в 5 разів вищий uptime, ніж Pusher.

Можливість Ably Pusher Socket.IO (self-hosted)
Затримка (P95) <50 мс <100 мс залежить від сервера
Збереження історії до 30 днів 24 години немає вбудованої
Глобальна інфраструктура 180+ PoP ~10 PoP немає
Token auth з capability вбудовано через проксі потрібна реалізація
SLA 99.999% 99.95% немає

Як забезпечити безпеку real-time каналів?

Безпека будується на трьох рівнях: транспорт (TLS 1.3), аутентифікація (token auth) та авторизація (capability). Ably підтримує IP-білі списки. Ми завжди використовуємо токенну аутентифікацію на клієнті — API-ключ ніколи не передається. Для кожного clientId задаються права: subscribe, publish, presence. Приклад налаштування нижче.

Приклад генерації токена з capability
const tokenParams = {
  clientId: req.user.id,
  capability: {
    [`prices:*`]: ['subscribe'],
    [`notifications:${req.user.id}`]: ['subscribe'],
    [`user-actions:${req.user.id}`]: ['publish', 'subscribe']
  },
  ttl: 60 * 60 * 1000
};
const tokenRequest = await ably.auth.createTokenRequest(tokenParams);

Як ми це робимо

Ми використовуємо серверний REST-клієнт Ably для публікації даних та клієнтський Realtime-клієнт з token auth на фронтенді. Нижче — типовий код для публікації та підписки.

Сервер — публікація даних

import Ably from 'ably';

const ably = new Ably.Rest({
  key: process.env.ABLY_API_KEY
});

// Публикация обновления цены (например, биржевой котировки)
async function publishPriceUpdate(symbol: string, price: number) {
  const channel = ably.channels.get(`prices:${symbol}`);

  await channel.publish('price-update', {
    symbol,
    price,
    timestamp: Date.now(),
    change: calculateChange(symbol, price)
  });
}

// Bulk publish для нескольких символов
async function publishBatch(updates: PriceUpdate[]) {
  await Promise.all(
    updates.map(u => publishPriceUpdate(u.symbol, u.price))
  );
}

Токени авторизації (Ably Token Auth)

Ніколи не передавайте API ключ на клієнт — використовуйте token auth:

// Сервер генерирует токен для клиента
app.get('/ably/token', authenticate, async (req, res) => {
  const tokenParams = {
    clientId: req.user.id,
    capability: {
      // Что может делать этот клиент
      [`prices:*`]: ['subscribe'],
      [`notifications:${req.user.id}`]: ['subscribe'],
      [`user-actions:${req.user.id}`]: ['publish', 'subscribe']
    },
    ttl: 60 * 60 * 1000  // 1 час
  };

  const tokenRequest = await ably.auth.createTokenRequest(tokenParams);
  res.json(tokenRequest);
});

Клієнт (React)

import Ably from 'ably';
import { useEffect, useState } from 'react';

function usePriceUpdates(symbols: string[]) {
  const [prices, setPrices] = useState<Record<string, number>>({});

  useEffect(() => {
    const client = new Ably.Realtime({
      authUrl: '/ably/token',
      authHeaders: { Authorization: `Bearer ${getToken()}` }
    });

    const channels = symbols.map(symbol => {
      const channel = client.channels.get(`prices:${symbol}`);

      channel.subscribe('price-update', (message) => {
        setPrices(prev => ({
          ...prev,
          [message.data.symbol]: message.data.price
        }));
      });

      return channel;
    });

    return () => {
      channels.forEach(ch => ch.unsubscribe());
      client.close();
    };
  }, [symbols.join(',')]);

  return prices;
}

Історія повідомлень

Ably зберігає історію — новий підписник може отримати пропущені повідомлення:

// Получить последние 100 сообщений из канала
const channel = client.channels.get('notifications');
const history = await channel.history({ limit: 100, direction: 'backwards' });

for (const item of history.items) {
  console.log(item.data, item.timestamp);
}

Які типові помилки виникають при інтеграції Ably?

  • Публікація без історії. Якщо вимкнути persisted, пропущені дані не відновляться. Завжди вмикайте збереження історії для каналів.
  • Відсутність retry-логіки. При тимчасових помилках клієнт повинен автоматично перепідключатися — Ably SDK робить це за замовчуванням.
  • Занадто широкі capability. Обмежуйте права каналів: клієнт не повинен публікувати в чужі канали.
Сценарій Рекомендований канал
Біржові котирування prices:{symbol} з persisted=true
Чат chat:{roomId} з історією 24h
Спільне редагування doc:{docId} з presence та cap
Сповіщення notifications:{userId} з push

Як Ably гарантує доставку повідомлень при збоях?

Ably використовує протокол надійної доставки з підтвердженням отримання та автоматичним повторенням при невдачі. Повідомлення зберігаються в черзі до тих пір, поки клієнт не підтвердить отримання. Завдяки глобальній мережі PoP, при відмові одного вузла трафік автоматично перенаправляється на найближчий робочий. Це забезпечує доставку без втрат навіть при короткочасних мережевих проблемах.

Що входить в інтеграцію під ключ

  • Архітектура каналів та подій — проектуємо структуру під ваш бізнес-сценарій.
  • Token auth — генерація токенів з мінімальними правами.
  • Клієнтська підписка — React/Vue/Angular хуки для підписки на канали.
  • Моніторинг та логування — ставимо дашборди Ably для відстеження метрик.
  • Документація — опис схеми каналів, подій та приклади коду.
  • Навчання команди — 2-годинна сесія по роботі з Ably.
  • Технічна підтримка — 1 місяць після деплою.

Вартість володіння такою інтеграцією окупається за рахунок скорочення часу розробки на 2 тижні та зниження витрат на інфраструктуру на 30%.

Процес роботи

  1. Аналітика — розбираємо сценарії real-time: котирування, чат, спільне редагування.
  2. Проектування — визначаємо канали, події, права доступу.
  3. Реалізація — налаштовуємо серверну публікацію та клієнтську підписку.
  4. Тест — навантажувальне тестування з емуляцією тисяч одночасних з'єднань.
  5. Деплой — розгортання на production з моніторингом.

Терміни

  • Базова інтеграція pub/sub з token auth — 1–2 дні.
  • Повноцінне впровадження з історією, presence та моніторингом — 5–7 днів.

Вартість розраховується індивідуально. Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проект за один день. Замовте інтеграцію Ably під ключ.

Ably Documentation

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

Ми знаємо, як боляче, коли полінг вбиває сервер. Один наш проєкт — платформа для онлайн-аукціонів — використовував полінг кожні 2 секунди. Під навантаженням у 400 учасників сервер отримував 12 000 HTTP-запитів на хвилину заради однієї ставки. 90% відповідей — пусті. Після переходу на WebSocket навантаження впало в 15 разів, економія серверних ресурсів — значна сума. Замовте розробку 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% сесій, що зекономило значні кошти на трафіку.

WebSocket (Wikipedia) WebRTC (Wikipedia)

Як правильно вибрати транспорт: покрокова інструкція

  1. Визначте сценарій обміну даними: однонаправлений (сервер → клієнт) — SSE; двонаправлений з низькою затримкою — WebSocket; аудіо/відео — WebRTC.
  2. Оцініть вимоги до затримки. Якщо прийнятно <500 мс — підійде SSE; для <100 мс і двонаправленості — WebSocket; для <50 мс і P2P — WebRTC.
  3. Перевірте бюджет на інфраструктуру. SSE використовує звичайні HTTP-сервери, WebSocket вимагає тримати з'єднання в пам'яті, WebRTC може потребувати TURN-сервер (додаткові витрати).
  4. Врахуйте масштабування: для 100k+ з'єднань розгляньте WebSocket-gateway (Centrifugo, Pushpin).
Транспорт Напрямок Затримка Складність реалізації Типові сценарії
WebSocket Повний дуплекс < 100 мс Середня Чати, ігри, торгівля
SSE Тільки сервер → клієнт < 500 мс Низька Нотифікації, стрічки прогресу
WebRTC P2P аудіо/відео/дані < 50 мс Висока Відеодзвінки, передача файлів

Що таке CRDT і чим він кращий за Operational Transformation?

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

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

Порівняння бібліотек для спільного редагування

Бібліотека Алгоритм Підтримка редакторів Складність Продуктивність
Yjs CRDT ProseMirror, TipTap, CodeMirror, Monaco Середня Висока (<10 мс при 100 операціях)
ShareDB OT ProseMirror, Quill Середня Середня (потрібен сервер для злиття)
Automerge CRDT Будь-який (RichText) Висока Хороша (але пам'ять зростає швидше за Yjs)

Проблема: розмір Yjs-документа зростає через історію операцій. Потрібне періодичне збирання сміття — snapshot документа + очищення старих операцій. Без цього документ, над яким працювали рік, може важити 50 МБ.

Приклад heartbeat на WebSocket (Node.js)
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+ з'єднань на одній ноді. Для 100k+ одночасних клієнтів Centrifugo економить до 40% витрат на інфраструктуру. Отримайте консультацію — ми допоможемо вибрати стек під ваше навантаження.

Строки

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

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