Чат всередині відеоконференції: як реалізувати та інтегрувати

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

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

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Чат всередині відеоконференції: як реалізувати та інтегрувати
Середній
~3-5 днів
Часті запитання

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

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

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

  • 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
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    949

Чат всередині відеоконференції

У відеоконференції часто потрібен паралельний текстовий чат: швидке запитання, посилання на документ, коментар без переривання доповідача. Типова ситуація: 100+ учасників вебінару, спікер розповідає, а в чаті — лавина повідомлень. Без чату доводиться використовувати сторонні месенджери, втрачаючи контекст і відволікаючись. Рішення — вбудований текстовий чат, що працює одночасно з відео. Ми реалізуємо такий чат на базі LiveKit Data Messages або Socket.IO, з підтримкою особистих повідомлень, реакцій, файлів і збереженням історії. Типова архітектура: React-компонент на клієнті, сервер Node.js (Nest.js) для webhook та історії, LiveKit для відео та даних. За багаторічний досвід із WebRTC та десятки інтеграцій ми довели рішення до стабільної роботи під навантаженням. Чат передає повідомлення через WebRTC Data Channel або WebSocket. Для гарантованої доставки використовуємо reliable: true у LiveKit. Затримка не перевищує 50 мс навіть при 100+ учасниках. Особисті повідомлення маркуються полем isPrivate і доставляються лише адресату. Історія шифрується TLS, за потреби зберігається в PostgreSQL через webhook.

Чому текстовий чат критичний для відеоконференцій?

Без чату учасники змушені використовувати сторонні месенджери, втрачаючи контекст. Чат всередині конференції:

  • дозволяє поставити запитання, не перериваючи спікера;
  • залишає посилання та код у текстовому вигляді;
  • зберігає історію для тих, хто підключився пізніше.

Які технічні проблеми вирішуємо?

Затримки та синхронізація

Повідомлення мають доставлятися всім учасникам одночасно. Використовуємо Data Channel LiveKit (властивості reliable: true) — гарантує порядок і доставку. Альтернатива — Socket.IO з власною чергою. Типова помилка: надсилати повідомлення як unreliable — втрачаються при високому навантаженні. Наша тестова конференція з 100+ учасниками показала затримку менше 50 мс.

Приватність та безпека

Особисті повідомлення не повинні бачити інші. Ми маркуємо їх полем isPrivate і надсилаємо лише обраному учаснику через destinationIdentities. Історія шифрується при передачі (TLS). Додатково можна налаштувати фільтрацію нецензурної лексики.

Збереження історії

За замовчуванням LiveKit не зберігає чат. Ми підписуємося на webhook data_received і пишемо в PostgreSQL. Це дозволяє завантажити історію при реконнекті або після дзвінка. Без збереження чат існує лише під час конференції.

Як ми це робимо: LiveKit Data Messages vs Socket.IO

Критерій LiveKit Data Messages Socket.IO
Інфраструктура Вбудований канал у LiveKit Окремий WebSocket-сервер
Збереження історії Через webhook Напряму в БД
Управління кімнатами LiveKit Room Своя логіка
Затримка < 50 мс < 50 мс
Навантаження До 10 000 учасників Залежить від сервера

Згідно з документацією LiveKit, Data Channel забезпечує надійну доставку із затримкою менше 50 мс. LiveKit Data Messages у 2 рази швидші в інтеграції, ніж Socket.IO, при схожій функціональності. Коли обираємо LiveKit: якщо конференція вже використовує LiveKit для відео — додавання чату коштує 1 день без нового сервера. Коли обираємо Socket.IO: потрібен кастомний бекенд (фільтрація, модерація, боти). Піднімаємо окремий сервіс на Node.js.

Поширені помилки при інтеграції чату
  • Надсилання повідомлень як unreliable — втрата пакетів при піковому навантаженні.
  • Ігнорування webhook для збереження історії — чат не відновлюється після реконнекту.
  • Не врахування приватності — особисті повідомлення видні всім.

Приклад реалізації на React + LiveKit

Нижче — робочий код компонента чату. Надсилання повідомлень, прийом, реакції та особисті повідомлення.

// Надсилання повідомлення через LiveKit Data channel
async function sendChatMessage(
  room: Room,
  text: string,
  toParticipant?: string  // undefined = всім
): Promise<void> {
  const message = {
    id: crypto.randomUUID(),
    type: 'chat',
    text,
    senderName: room.localParticipant.name,
    senderId: room.localParticipant.identity,
    timestamp: Date.now(),
    isPrivate: !!toParticipant,
  };

  const data = new TextEncoder().encode(JSON.stringify(message));

  if (toParticipant) {
    // Особисте повідомлення конкретному учаснику
    const participant = [...room.remoteParticipants.values()]
      .find(p => p.identity === toParticipant);
    if (participant) {
      await room.localParticipant.publishData(data, {
        reliable: true,
        destinationIdentities: [toParticipant],
      });
    }
  } else {
    // Всім у кімнаті
    await room.localParticipant.publishData(data, { reliable: true });
  }
}

// Отримання повідомлень
room.on('dataReceived', (payload: Uint8Array, participant?: RemoteParticipant) => {
  const message = JSON.parse(new TextDecoder().decode(payload));
  if (message.type === 'chat') {
    addMessage(message);
  }
  if (message.type === 'reaction') {
    addReaction(message.targetMessageId, message.emoji, participant?.name);
  }
});
interface ChatMessage {
  id: string;
  text: string;
  senderName: string;
  senderId: string;
  timestamp: number;
  isPrivate: boolean;
  reactions: Record<string, string[]>;  // emoji → [userName]
}

function ConferenceChat({ room }: { room: Room }) {
  const [messages, setMessages] = useState<ChatMessage[]>([]);
  const [text, setText] = useState('');
  const [privateTo, setPrivateTo] = useState<string | null>(null);
  const bottomRef = useRef<HTMLDivElement>(null);

  const addMessage = useCallback((msg: ChatMessage) => {
    setMessages(prev => [...prev, { ...msg, reactions: {} }]);
    bottomRef.current?.scrollIntoView({ behavior: 'smooth' });
  }, []);

  const addReaction = useCallback((messageId: string, emoji: string, senderName: string) => {
    setMessages(prev => prev.map(m => {
      if (m.id !== messageId) return m;
      const existing = m.reactions[emoji] ?? [];
      return {
        ...m,
        reactions: { ...m.reactions, [emoji]: [...existing, senderName] },
      };
    }));
  }, []);

  useEffect(() => {
    const handler = (payload: Uint8Array) => {
      const msg = JSON.parse(new TextDecoder().decode(payload));
      if (msg.type === 'chat') addMessage(msg);
      if (msg.type === 'reaction') addReaction(msg.targetMessageId, msg.emoji, msg.senderName);
    };
    room.on('dataReceived', handler);
    return () => { room.off('dataReceived', handler); };
  }, [room, addMessage, addReaction]);

  const send = async () => {
    if (!text.trim()) return;
    await sendChatMessage(room, text, privateTo ?? undefined);
    setText('');
  };

  const sendReaction = async (messageId: string, emoji: string) => {
    const data = new TextEncoder().encode(JSON.stringify({
      type: 'reaction',
      targetMessageId: messageId,
      emoji,
      senderName: room.localParticipant.name,
    }));
    await room.localParticipant.publishData(data, { reliable: true });
    addReaction(messageId, emoji, room.localParticipant.name ?? '');
  };

  return (
    <div className="flex flex-col h-full bg-white border-l border-gray-200">
      {/* Повідомлення */}
      <div className="flex-1 overflow-y-auto p-4 space-y-3">
        {messages.map(msg => (
          <MessageBubble
            key={msg.id}
            message={msg}
            isOwnMessage={msg.senderId === room.localParticipant.identity}
            onReact={(emoji) => sendReaction(msg.id, emoji)}
          />
        ))}
        <div ref={bottomRef} />
      </div>

      {/* Вибір отримувача */}
      {privateTo && (
        <div className="px-4 py-1 bg-yellow-50 border-t border-yellow-200 flex justify-between">
          <span className="text-sm text-yellow-700">Особисте повідомлення → {privateTo}</span>
          <button onClick={() => setPrivateTo(null)} className="text-yellow-600 text-sm">✕</button>
        </div>
      )}

      {/* Введення */}
      <div className="p-4 border-t border-gray-200 flex gap-2">
        <input
          value={text}
          onChange={e => setText(e.target.value)}
          onKeyDown={e => e.key === 'Enter' && !e.shiftKey && (e.preventDefault(), send())}
          placeholder={privateTo ? `Особисте повідомлення...` : 'Повідомлення всім...'}
          className="flex-1 border rounded-lg px-3 py-2 text-sm focus:outline-none focus:ring-2 focus:ring-blue-500"
        />
        <button onClick={send} disabled={!text.trim()}
          className="px-4 py-2 bg-blue-600 text-white rounded-lg text-sm disabled:opacity-50">
          ↑
        </button>
      </div>
    </div>
  );
}

function MessageBubble({ message, isOwnMessage, onReact }) {
  const REACTIONS = ['👍', '❤️', '😂', '👏', '🎉'];

  return (
    <div className={`flex flex-col ${isOwnMessage ? 'items-end' : 'items-start'}`}>
      {!isOwnMessage && (
        <span className="text-xs text-gray-500 mb-1">{message.senderName}</span>
      )}
      <div className={`max-w-xs px-3 py-2 rounded-2xl text-sm ${
        message.isPrivate ? 'bg-yellow-100 border border-yellow-300' :
        isOwnMessage ? 'bg-blue-600 text-white' : 'bg-gray-100'
      }`}>
        {message.text}
        {message.isPrivate && (
          <span className="text-xs ml-2 opacity-60">🔒</span>
        )}
      </div>

      {/* Реакції */}
      <div className="flex gap-1 mt-1">
        {Object.entries(message.reactions).map(([emoji, users]) => (
          <span key={emoji} className="text-xs bg-gray-100 rounded-full px-2 py-0.5"
            title={users.join(', ')}>
            {emoji} {users.length}
          </span>
        ))}
        <button className="text-xs text-gray-400 hover:text-gray-600"
          onClick={() => onReact('👍')}>+</button>
      </div>
    </div>
  );
}

Як зберегти історію чату?

Якщо потрібна історія після дзвінка — зберігаємо в базу через webhook:

// Сервер слухає події LiveKit webhook
app.post('/api/webhooks/livekit', async (req, res) => {
  const event = receiver.receive(req.body, req.headers['authorization']);

  if (event.event === 'data_received') {
    const msg = JSON.parse(new TextDecoder().decode(event.data));
    if (msg.type === 'chat') {
      await db.chatMessages.create({
        roomName: event.room.name,
        senderId: event.participant.identity,
        text: msg.text,
        isPrivate: msg.isPrivate,
        timestamp: new Date(msg.timestamp),
      });
    }
  }

  res.status(200).end();
});

Процес впровадження чату у ваш сервіс

  1. Аналіз поточної архітектури — з'ясовуємо, чи використовується вже LiveKit або інше відео, визначаємо вимоги до історії та приватності.
  2. Вибір стеку — LiveKit Data Messages або Socket.IO + PostgreSQL.
  3. Інтеграція клієнта — вбудовуємо React-компонент у ваш інтерфейс, налаштовуємо авторизацію.
  4. Серверна частина — webhook для історії, API для завантаження попередніх повідомлень.
  5. Тестування — перевіряємо під навантаженням (100+ учасників), затримки, приватність.
  6. Деплой — розміщення на вашому сервері або в хмарі.
Етап Термін
Аналіз і вибір стеку 0.5 дня
Інтеграція клієнта 0.5–1 день
Серверна частина 1–2 дні
Тестування 0.5 дня
Деплой 0.5 дня

Що входить у результат?

  • React-компонент чату з підтримкою особистих повідомлень, реакцій і файлів.
  • Серверна частина для збереження історії (якщо потрібно).
  • Документація по API та компонентах.
  • Підтримка протягом 30 днів після здачі.

Терміни та вартість

Базова версія (без історії) — від 1 до 2 днів. Версія з історією та особистими повідомленнями — від 2 до 4 днів. Вартість розраховується індивідуально, залежить від складності інтеграції. Економія на інфраструктурі порівняно з окремим чат-сервером становить до 30%. Зв'яжіться з нами для оцінки проєкту — надішлемо комерційну пропозицію протягом дня. Отримайте консультацію з інтеграції безкоштовно. Замовте інтеграцію чату у свій сервіс.

Наш досвід — багаторічна розробка веб-додатків, десятки успішних проєктів із LiveKit та WebRTC. Гарантуємо стабільну роботу чату під навантаженням.

Розробка систем реального часу: 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).

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