Я всегда хотел поболтать в реальном времени.

Я сделал это несколько лет назад в 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 часов в день, если вы не укажете серверу вручную.