Websockets in microservices architecture

Question

Let's say we have a notification service which read an event from message queue and notify all web clients in real time. I know how web socket work but i am puzzled when there is an API gateway in between then how web socket connection is maintained between client, API gateway and notification service.

Please help! Thanks

Edit: Architecture:

Solution 1

Websockets

A websocket connection opened by a client must eventually connect to a websocket server.

API Gateway

The job of the API gateway is to accept an incoming websocket connection from a client and correctly route it to a websocket server. An API gateway will redirect ALL data sent from a client websocket to the correct back-end service and will maintain the connection the entire time.

How everything works together...

The root of your question is "how can I have a client with a websocket connection receive a live update from the notification service?". The simplest answer would be to start a websocket server on the Notification Service, let each client connect to the API gateway, then have the API gateway route that traffic to the Notification Service.

• Client <=> API Gateway <=> Notification Service

Taking it further...

If you have further requirements by the clients to transform the data coming out of the Notification Service, then you could:

1. Stuff that business logic into the Notification Service (not recommended).
2. Or, add another service with the transformation logic between the API gateway and the Notification Service which is called the Backends for Frontends microservice design pattern (recommended):
   • Client <=> API Gateway <=> Notification Server (transformation logic) <=> Notification Service.
3. Or, if your API gateway of choice is designed to hold business logic and transform data; put the transformation logic directly in the API gateway.

Solution 2

You should not mix the concepts. An API Gateway is hiding your infrastructure from your client. It can be a single frontend for many services, in the "Backends for frontends" sense. It can also be responsible for many other things, such as authentication.

A web socket server can sit in parallel to your API Gateway. Another domain or another port. Let's say you use a web socket server like http://nchan.io. The events from your application go through your message broker or whatever messaging integration pattern you use. A consumer can pick up this events and publish them through the Nchan server. Clients (for example Browsers) connect to the Nchan server and will be informed about the events.

Solution 3

Coming across this question over 2 years later, I doubt the OP is still working on this problem, but for myself and future visitors here is what I would recommend:

The API gateway is the main entry point for one or more clients into the system (multiple gateways can be employed if using the backends-for-frontends pattern). The WebSocket client/server is appropriate for one or more of those clients, but stands separate from the API gateway. Each client would maintain a separate connection to the WebSocket server. Within your application and its services, whenever an event is published to your message broker, the WebSocket server would be subscribed to all events which require a notification, and would relay those messages back to each connected client. It would be up to either the WebSocket server to determine which clients should receive a given notification, or the WebSocket client to determine if it should handle a given notification or ignore it (or both depending on where the logic lives).