Допустим, у нас есть служба уведомлений, которая считывает событие из очереди сообщений и уведомляет всех веб-клиентов в режиме реального времени. Я знаю, как работает веб-сокет, но я озадачен, когда между ними есть шлюз API, а затем то, как поддерживается соединение веб-сокета между клиентом, шлюзом API и службой уведомлений.
Пожалуйста помоги! Спасибо
Изменить: Архитектура: 
Соединение через веб-сокет, открытое клиентом, должно в конечном итоге подключиться к серверу веб-сокета.
Задача шлюза API состоит в том, чтобы принять входящее соединение через веб-сокет от клиента и правильно направить его на сервер веб-сокета. Шлюз API будет перенаправлять ВСЕ данные, отправленные с клиентского веб-сокета, на правильную серверную службу и будет поддерживать соединение все время.
Корень вашего вопроса заключается в том, «как я могу заставить клиента с подключением к веб-сокету получать живое обновление от службы уведомлений?». Самым простым ответом было бы запустить сервер веб-сокетов в службе уведомлений, позволить каждому клиенту подключиться к шлюзу API, а затем шлюз API направляет этот трафик в службу уведомлений.
Если у вас есть дополнительные требования клиентов по преобразованию данных, поступающих из службы уведомлений, вы можете:
Не следует смешивать понятия. Шлюз API скрывает вашу инфраструктуру от вашего клиента. Это может быть единый интерфейс для многих сервисов в смысле «Бэкэнды для интерфейсов». Он также может отвечать за многие другие вещи, такие как аутентификация.
Сервер веб-сокетов может располагаться параллельно вашему шлюзу API. Другой домен или другой порт. Допустим, вы используете сервер веб-сокетов, например http://nchan.io. События из вашего приложения проходят через вашего брокера сообщений или любой другой шаблон интеграции обмена сообщениями, который вы используете. Потребитель может получить эти события и опубликовать их через сервер Nchan. Клиенты (например, браузеры) подключаются к серверу Nchan и будут проинформированы о событиях.
Столкнувшись с этим вопросом более 2 лет спустя, я сомневаюсь, что ОП все еще работает над этой проблемой, но для себя и будущих посетителей я бы порекомендовал вот что:
Шлюз API — это основная точка входа для одного или нескольких клиентов в систему (можно использовать несколько шлюзов, если используется шаблон «бэкенды для интерфейсов»). Клиент/сервер WebSocket подходит для одного или нескольких таких клиентов, но стоит отдельно от шлюза API. Каждый клиент будет поддерживать отдельное соединение с сервером WebSocket. В вашем приложении и его службах всякий раз, когда событие публикуется в вашем брокере сообщений, сервер WebSocket будет подписываться на все события, требующие уведомления, и будет передавать эти сообщения обратно каждому подключенному клиенту. Либо сервер WebSocket должен определить, какие клиенты должны получать данное уведомление, либо клиент WebSocket должен определить, должен ли он обрабатывать данное уведомление или игнорировать его (или и то, и другое, в зависимости от того, где живет логика).
