32

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: enter image description here

Vipul Goyal
  • 1,068
  • 2
  • 10
  • 18
  • 1
    As I presume you know an incoming webSocket connection from a browser needs to connect to a webSocket server. So, if you want to send a message to one or more clients connected via the webSocket server, then you have to ask the webSocket server to do that on your behalf. If your notification service is some other microservice, then it needs to know how to send the webSocket server a message that will cause it to send out the notification you want. – jfriend00 Nov 29 '17 at 04:26
  • 2
    You are throwing around the term API gateway as if that is a standard term and we would know exactly what that is. It is not and we do not. If you want more help with that, then you will have to describe in a lot more detail how your architecture works, what processes you have, how requests flow through the various processes, where webSockets are connected, etc... – jfriend00 Nov 29 '17 at 04:28
  • 2
    Thanks for your reponse. But API gateway I am referring is in context of microservice architecture. http://microservices.io/patterns/apigateway.html – Vipul Goyal Nov 29 '17 at 08:37
  • I rather doubt people can help you when you just refer to generic terms like this without showing YOUR specific architecture. Your notification service needs to contact whatever process maintains the webSocket connections. How you do that depends entirely upon your specific architecture. – jfriend00 Nov 29 '17 at 08:39
  • 1
    I have edited question with very basic architecture. Hope it helps – Vipul Goyal Nov 29 '17 at 08:56

3 Answers3

11

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.
alextaujenis
  • 111
  • 1
  • 4
  • What if the Api Gateway doesn't support websockets routing? for example Netflix Zuul – Johnny Willer Jan 01 '20 at 23:42
  • It looks like Netflix Zuul 2 supports websockets, but I'm not sure it's a full-blown proxy. If your API gateway doesn't support websockets then you can add another server to your infrastructure that does (such as Nginx). However, this is going to dramatically increase complexity. I'd recommend trying to figure out the native features of your API gateway for real-time messages, or select a different API gateway with support for the features you need. – alextaujenis Feb 17 '20 at 15:01
  • How does this work for many microservices? Say the client needs to receive updates that are handled internally by 5 different services, does this mean the client now has to keep 5 websocket connections open to the API gateway? One connection per microservice? – Douglas Gaskell Mar 07 '21 at 20:16
  • If a client needs to receive updates from many different (internal) microservices then it's really up to you how to architect this. You could let the client open multiple websocket connections, or you could combine the websockets (with another microservice internally) so the client only opens one connection. You personally need to weigh the tradeoffs of making these infrastructure decisions, otherwise it will become difficult or impossible to move forward after a certain point in development. If you can't think through these decisions then just pick one and see how it turns out. – alextaujenis Mar 09 '21 at 01:58
5

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.

marein
  • 61
  • 3
  • 1
    My confusion is notification to clients will happen through API gateway or directly to clients. As per my understanding initially connection will be established through API gateway and then all communication will happen directly between notification server and clients. – Vipul Goyal Dec 01 '17 at 01:42
  • The clients go through your API Gateway if they want request your services behind it. The clients can directly talk to your Web Socket Server. There is no need to call the API Gateway initially. Should the user be authenticated before they talk to the Web Socket Server? We may need more information about your current setup and what you have tried. – marein Dec 01 '17 at 21:55
  • So for an application, say a game, where you almost exclusively communicate via websockets, the websocket server is essentially taking on the role of the API gateway? Since you still have microservices that the websocket server needs to communicate with. – Douglas Gaskell Mar 07 '21 at 20:19
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).

Jason Miesionczek
  • 13,718
  • 14
  • 73
  • 108