Я завжди хотів спілкуватися в режимі реального часу.

Я зробив це багато років тому в PHP + Ajax + Mysql і зламав свій сервер. Потім я спробував із Flash + текстовий файл. Я здався і 10 років не пробував. Але нещодавно я чув про веб-хуки та веб-сокети. І вони обидва здаються способом зробити це, але я насправді не зовсім розумію різницю. Хто-небудь може пояснити?

Веб-хуки

Веб-хуки призначені для зв'язку між серверами. Вони працюють одним сервером, повідомляючи іншому серверу, що він хоче, щоб дані надсилалися на певну URL-адресу, коли щось трапляється.

У цій статті розповідається про деякі способи використання веб-хуків у популярних сервісах. Ця організація багато говорить про їх використання в контексті RESTful API.

Веб-розетки

Веб-сокети (як правило) - це зв’язок між сервером та браузером. Сервер розміщує веб-сервер, і клієнти можуть відкрити з'єднання з цим сервером. Зараз це популярно здебільшого тому, що воно швидше та менше вимагає ресурсів, ніж старіші способи вирішення проблеми, такі як довгі опитування / COMET .

Це можна підключити 2 сервера з допомогою WebSockets , але це звичайно не те , що вони використовуються.

Плутанина

Незважаючи на те, що одним із них є (виключно) сервер-сервер, а одним є (в основному) браузер-сервер, ці технології часто обговорюються в тих самих місцях, майже як вони вирішують одні й ті ж проблеми. Якщо ви подивитеся на ланцюг досить високо, ви побачите, що вони обидва вирішують проблему спілкування в реальному часі, але вони вирішують різні аспекти цієї проблеми по-різному .

Одна ситуація, коли може бути пряме порівняння, полягає в тому, що ви створюєте API, який буде використовуватися стороннім сервером. У такій ситуації ви можете надати API веб-хука або API веб- розетки . Обидва дозволяють третій стороні швидко отримувати оновлення:

• Якщо ви виберете веб-хуки, сторонній стороні все одно доведеться знайти спосіб перенести зміни, про які ви їм повідомляєте, у браузери свого клієнта.
• Якщо ви надаєте API веб-розетки, третя сторона може просто налаштувати свій сайт, щоб кожен їх користувач підключався безпосередньо до вашого веб-розетки API, і їх сервери повинні виконувати менше роботи.

Ось додаткова інформація для вибору між веб-хуками та веб-сокетами.

Зв’язок між серверами через веб-сокети став популярним серед нового покоління додатків чат-ботів. Зараз багато чат-ботів працюють через веб-сокети, забезпечуючи головну перевагу - не вимагати загальнодоступної URL-адреси для внутрішніх приватних ботів. У цьому середовищі наведено кілька рекомендацій щодо того, коли слід розглядати можливість використання веб-хуків та веб-сокетів.

Веб-розетки

• Якщо ваша програма є програмою для браузера, використовуйте веб-сокети, оскільки вона не може отримувати веб-хуки.
• Якщо ваша програма - це серверна програма, яка отримує повідомлення від служби через Інтернет, і ви не хочете відкривати свій брандмауер, розгляньте веб-розетки. Деякі компанії вимагають перевірки захисту інформації перед відкриттям таких з’єднань.

Веб-хуки

• Якщо вашій програмі серверного додатку потрібно зробити багато підписок, будьте готові обробляти обсяг відкритих підключень до веб-сокета до вашого сервера ( див. Цю статтю для 1 М підключень до веб- розетки ), або перейдіть на веб-хуки. Деякі популярні чат-боти перейшли з веб-сокетів на веб-хуки, щоб покращити масштабованість.
• Якщо ваш серверний додаток працює як хмарна функція (AWS Lambda, Google Cloud Functions тощо), використовуйте веб-хуки, оскільки ваш додаток не буде тримати з’єднання з веб-розеткою відкритим.
• Якщо ваш серверний додаток працює на безкоштовному рівні Heroku, використовуйте веб-хуки, тому що ваш Dyno переходить у режим сну і повинен спати 6 годин на день, якщо ви вручну не вкажете своєму серверу спати.