Переваги мультиканального бота Telegram WhatsApp Viber
Інтегрувати бота в одному месенджері нескладно. Складність починається, коли потрібно покрити Telegram, WhatsApp та Viber одночасно — і при цьому не перетворити кодову базу на три незалежні купи логіки. Ми вирішуємо це через єдиний шар бізнес-логіки, ізолюючи специфіку кожної платформи за інтерфейсом адаптера. Економія на розробці трьох окремих ботів становить 40–60% бюджету, а час виходу на ринок скорочується вдвічі-втричі.
Чому три боти — не три рази більше роботи, а три рази більше помилок? — мультиканальний бот telegram
Кожна платформа живе за своїми правилами. Telegram Bot API віддає вебхук синхронно і очікує відповідь 200 OK протягом 5 секунд — якщо бекенд задумався, платформа почне повторювати запити, і бот отримає дублі. WhatsApp Business API (Meta Cloud API) працює інакше: вебхук для верифікації приходить GET-запитом з hub.challenge, і якщо не відповісти правильним значенням, вебхук просто не зареєструється — тиха помилка, яку легко пропустити.
Viber відрізняється форматом rich media: тип rich_media з кнопками працює тільки при відправці через send_message, а не через reply API. Розробники, які переносять логіку з Telegram (де inline keyboard вішається прямо на будь-яке повідомлення), натикаються на це в перший же день.
Окрема історія — формат вкладень. Telegram приймає multipart/form-data при відправці файлу напряму, WhatsApp вимагає спочатку завантажити медіа через POST /v1/media і отримати media_id, і тільки потім слати його в повідомленні. Viber обмежує розмір файлу 200 МБ і підтримує строго визначені MIME-типи. Якщо вся ця логіка розмазана по одному сервісу без чіткої абстракції, супроводжувати це через пів року неможливо.
Як адаптерний патерн позбавляє дублювання?
Правильний підхід — ввести інтерфейс BotAdapter з методами sendMessage, sendFile, parseIncoming. Кожна платформа — своя реалізація.
// Android (Kotlin) — приклад адаптерного шару interface BotAdapter { suspend fun sendMessage(chatId: String, text: String, buttons: List<BotButton>? = null) suspend fun sendFile(chatId: String, fileUrl: String, mimeType: String) fun parseIncoming(payload: String): BotMessage } class TelegramAdapter(private val token: String) : BotAdapter { private val client = OkHttpClient() override suspend fun sendMessage(chatId: String, text: String, buttons: List<BotButton>?) { val body = buildTelegramPayload(chatId, text, buttons) client.newCall(Request.Builder() .url("https://api.telegram.org/bot$token/sendMessage") .post(body).build()).execute() } // ... } На iOS патерн той самий — протокол BotAdapter і три struct-реалізації через URLSession. У Flutter зручно використовувати абстрактний клас з dio під капотом. Бізнес-логіка (розпізнавання команд, FSM діалогу, робота з базою) живе вище — вона не знає, звідки прийшло повідомлення. Це скорочує код на 40–60% порівняно з трьома незалежними реалізаціями.
Управління станом діалогу (FSM)
Для будь-якого нетривіального бота потрібен скінченний автомат станів. Зберігати userState в пам'яті — антипатерн: при рестарті сервісу всі діалоги скидаються. На практиці ми використовуємо Redis з TTL (наприклад, 30 хвилин неактивності скидають сесію) або таблицю в PostgreSQL з updated_at.
Ключ стану — {platform}:{chatId}, це дозволяє одному користувачеві мати незалежні діалоги в різних месенджерах, що іноді потрібно за бізнес-логікою.
| Сховище | Переваги | Недоліки |
|---|---|---|
| In-memory | Максимальна швидкість | Втрата даних при рестарті |
| Redis | TTL, швидкий доступ | Додатковий сервіс |
| PostgreSQL | Надійність, ACID | Вища затримка |
Специфіка мобільного застосунку
Якщо бот вбудовується не в серверний сервіс, а безпосередньо в мобільний застосунок — потрібна WebSocket-підписка або polling. Для Telegram у мобільному контексті це getUpdates з long polling через BackgroundFetch (iOS) або WorkManager (Android). Тримати постійний WebSocket для бота у фоні iOS не дасть — система вб'є процес. Правильний патерн: push-сповіщення від сервера будить застосунок, воно робить один getUpdates, обробляє чергу і засинає.
WhatsApp Cloud API у мобільному застосунку потребуватиме серверного проксі — напряму з мобільного клієнта звертатися до Meta API не можна (потрібен верифікований бізнес-акаунт на стороні сервера). Це часто дивує команди, які хочуть «легку» інтеграцію.
Порівняння API месенджерів
| Параметр | Telegram | WhatsApp (Cloud API) | Viber |
|---|---|---|---|
| Формат вебхука | POST, відповідь 200 OK | GET (верифікація), POST | POST, відповідь 200 OK |
| Відправка файлів | multipart/form-data | Завантаження через /v1/media → media_id | max 200 MB, строгий MIME |
| Rich media | Inline keyboard на будь-яке повідомлення | Кнопки actions через interactive | Тільки через send_message, не reply |
| Таймаут вебхука | 5 секунд | 20 секунд | 30 секунд |
Процес роботи
Спочатку — аудит сценаріїв: які команди, чи потрібні кнопки/каруселі, чи є файловий обмін, чи потрібна оплата (Telegram Payments vs WhatsApp Pay). Це визначає складність адаптерів.
Далі: проектування FSM, реалізація адаптерів по черзі (Telegram першим — найзріліший API), інтеграція з основною логікою, навантажувальне тестування вебхуків (до 1000 запитів/хв). Окремий етап — моніторинг: логування вхідних payload з маскуванням персональних даних, алерти на delivery_failed у Viber та невдалі верифікації вебхуків.
Типові помилки при інтеграції
- Пропуск верифікації вебхука WhatsApp → вебхук не реєструється.
- Використання reply API для Viber rich media → кнопки не відображаються.
- Зберігання стану в пам'яті → втрата діалогів при рестарті.
- Відсутність таймаутів на Telegram → дублюючі вебхуки.
- Прямий виклик Meta API з мобільного застосунку → блокування.
Що входить в роботу (deliverables)
- Аудит сценаріїв та вимог до бота
- Проектування FSM та адаптерного шару
- Реалізація адаптерів для Telegram, WhatsApp, Viber
- Інтеграція з серверною частиною та мобільним застосунком
- Навантажувальне тестування (до 1000 вебхуків/хв)
- Моніторинг та алерти (логи, маскування PII)
- Документація та навчання команди
- Пост-релізна підтримка (3 місяці)
Орієнтири за термінами
Бот в одному месенджері з базовими командами — 3–5 днів. Мультиканальна реалізація з FSM, файлами, кнопками та серверною частиною — 2–4 тижні. Якщо потрібна інтеграція з CRM або платіжними системами — окрема оцінка після аналізу вимог.
App Store Review Guidelines Section 4.2 приписує мінімальну функціональність, тому бот повинен працювати без підписок. Ми враховуємо це при проектуванні. Маємо 5+ років досвіду в розробці мобільних та серверних рішень, реалізували понад 50 інтеграцій з месенджерами. Наші клієнти економлять до 60% бюджету на розробці та отримують рішення за 2–4 тижні. Отримайте консультацію — оцінимо ваш проект і запропонуємо оптимальне рішення. Замовте розробку мультиканального бота вже сьогодні.