Протокол WebSocket (веб-сокет, WS) обеспечивает возможность обмена данными между браузером и сервером через постоянное соединение. Данные передаются по нему в обоих направлениях в виде «пакетов», без разрыва соединения и дополнительных HTTP-запросов.
WebSocket особенно хорош для сервисов, которые нуждаются в постоянном обмене данными, например, чаты, онлайн игры, работающие в реальном времени торговые площадки и т.д.
В качестве примера создадим бэкенд для простого чата. Необходимо предусмотреть базовые возможности:
- Отправка сообщений в чат.
- Определение авторства сообщения.
- Уведомления о действиях. Например, вход нового участника в чат, выход из чата, индикатор набора текста (кто-то печатает…)
Модель базы данных
Начнем с создания модели для базы данных. Даже если мы изначально не планируем сохранять в базе данных сообщения и историю переписки, нам все равно потребуется модель, чтобы сделать отправку сообщений и уведомлений структурированной.
Создадим универсальную модель chat_event, которая содержит:
- Связь с пользователем. Любое сообщение включает в себя информацию о том, к какому пользователю оно относится.
- Поле type (enum) с 4 возможными вариантами. Connected и Disconnected - для уведомлений о подключении или отключении пользователя. Typing - для передачи информации о том, что пользователь в данный момент пишет новое сообщение. Message - для стандартного текстового сообщения.
- Message (text) - сам текст сообщения.
Конфигурация эндпойнта
Следующий шаг разработки немного отличается от стандартного подхода, характерного для других функций приложения. Обычно происходит создание бизнес-процесса, а после настраивается эндпойнт для его запуска. В случае с вебсокетами все происходит иначе и отправной точкой становится создание эндпойнта, на основе триггеров которого далее создаются бизнес-процессы.
Перейдем в раздел эндпойнтов и создадим новый эндпойнт, выбрав соответствующий вариант - WebSocket Endpoint.
Для вебсокетов отсутствует выбор метода запроса - он всегда GET. Укажем простой URL - /chat/ и создадим для него группу с аналогичным названием.
Далее необходимо создать переменные, которые будут определять формат обмена данными в рамках вебсокета.
- Client-to-Server. Аналогичны входящим параметрам для стандартных бизнес процессов. В нашем примере создадим простую текстовую переменную message (на сервер будем отправлять обычные текстовые сообщения).
- Server-to-Client. А тут создаются переменные для обратной связи, отправки данных от сервера пользователю. Обратите внимание на то, что это не то же самое, что и ответ на запрос пользователя. И хотя он может быть отправлен в качестве реакции на действия пользователя, чаще его причиной являются какие-то внешние события. В нашем примере сервер будет присылать уведомления о всех событиях в чате, поэтому установим в качестве переменной модель chat_event.
После создания переменных можно переходить к главному - созданию логики работы вебсокета. Она основана на триггерах, которые срабатывают при получении нового сообщения по вебсокету, а также при установлении или разрыве подключения.
Создание бизнес процесса
Воспользуемся триггером connect и создадим бизнес процесс для него. Он будет запускаться в тот момент, когда пользователь будет устанавливать соединение с вебсокетом и его задача будет заключаться в том, чтобы разослать всем подключенным пользователям уведомление об этом.
Обратите внимание на то, что стартовый блок включает в себя два параметра: User ID и Connection ID. Таким образом можно не только сразу же определить пользователя, который установил соединение, но и получить уникальный идентификатор данного соединения. В дальнейшем этот идентификатор можно использовать, например, для адресной отправки сообщений или для того, чтобы принудительно разорвать соединение.
Создадим все необходимые шаги бизнес-процесса:
- Make User. Воспользуемся стартовым параметром User ID для создания модели пользователя.
- Make chat_event. Создадим модель уведомления о событии. Свяжем ее с пользователем, использовав модель, созданную на предыдущем шаге, а также выберем тип события и установим Type = Connected. Параметр message не используем, так как в данном случае передается не сообщение, а уведомление о подключении.
- WSS Connections /chat/. С помощью данного блока получим список всех активных соединений вебсокета.
- For Each Loop. Используем массив соединений в качестве параметра цикла, в котором и произведем отправку уведомлений каждому подключенному пользователю.
- Expand Websocket Connection. Развернем информацию о соединении, чтобы получить Connection ID.
- WSS Send /chat/. Используем Connection ID и сформированный chat_event для отправки уведомления.
Использование Postman для тестирования вебсокетов
На данном этапе вебсокет, хоть и не обладает значительным функционалом, уже работоспособен и его можно протестировать в деле. Для этого можно воспользоваться любым инструментом, позволяющим работать с вебсокетами. В качестве примера рассмотрим, как это сделать с помощью Postman.
Необходимо нажать кнопку New и выбрать WebSocket Request
Необходимо указать URL для вебсокета. Его можно узнать с помощью Swagger, где вебсокет присутствует в общем списке с остальными эндпойнтами.
В отличие от стандартных запросов, вебсокеты работают по протоколу wss, поэтому необходимо заменить https на wss. В итоге должен получиться подобный URL: wss://qvlxglh-app.apms.io/api/chat/
Далее к запросу необходимо добавить токен аутентификации, так как соединение не может быть анонимным. Нужно создать заголовок Authorization со значением подобным Bearer lBCiunRWg6BfogDrLml4jrC4iJiWucKo. Разумеется, вместо lBCiunRWg6BfogDrLml4jrC4iJiWucKo нужно вставить собственный токен, который можно получить в результате авторизации (эндпойнт POST /auth/).
Если все сделано правильно, то по нажатию на кнопку Connect будет установлено соединение, а также получено первое сообщение со стороны сервера, бизнес процесс для отправки которого был создан ранее.
При этом можно убедиться, что получение сообщений от сервера происходит не только как реакция на какие-то запросы от нас. Они могут быть вызваны действиями других пользователей. Для проверки этого, можно в другой вкладке установить соединение с использованием токена аутентификации другого пользователя. Сообщение от сервера с уведомлением об этом придет во все вкладки с активным соединением.
Бизнес процесс для сообщений
Теперь можно продолжить развитие возможностей вебсокета и создать бизнес процесс для обмена сообщениями. Кстати, отправлять сообщения можно уже сейчас, вот только без предварительного создания логики в этом нет смысла, сообщение не приведет к какой-либо реакции. Поэтому вернемся в настройки эндпойнта и создадим бизнес процесс для триггера receive.
Во многом он будет похож на предыдущий бизнес процесс. При получении сообщения нужно будет сформировать chat_event и выполнить рассылку уведомлений об этом для всех участников чата. Отличие в том, что в chat_event нужно будет добавить само сообщение, а в список рассылки не нужно включать автора сообщения.
В первой части бизнес процесса используются те же самые блоки. В блоке Make chat_event необходимо установить type = message и присоединить само сообщение из стартового блока.
В цикле необходимо выполнить проверку (блок Equal) и отправлять сообщение только в том случае, если идентификатор соединения получателя не совпадает с идентификатором соединения отправителя (If-Else = False).
Можно опубликовать результат и приступить к тестированию. Обратите внимание на то, что самое сообщение представлено в формате JSON, поэтому, при использовании переменной message, оно будет выглядеть подобным образом:
{"message":"Some text here"}
В приведенном примере видно получение уведомления о подключении к чату, отправка собственного сообщения (Hi!) и получение ответа (Glad to see you!)
На этом создание основы бэкенда для чата с использованием вебсокетов закончено. Можно приступать к созданию фронтенда и разработать собственное приложение с возможностью обмена сообщениями в реальном времени.
