How to hide multiple websockets services behind an API Gateway?

Question

I'm working on a project that has multiple microservices behind a API Gateway and some of them expose WebSockets API.

The WebApp needs to be able to interact with those APIs.

.

Those WebSocket API can be built with frameworks that have their own protocols, using socket.io or not etc.

The main goal of this reflexion is to be able to scale and keep flexibility on my WebSockets APIs implementation.

I thought about two solutions :

• The first one is to simply proxy requests on the gateway, the webapp will have to open a websocket for each microservice, this looks like a design flaw to me.

• The other one is to create a "Notifier Service" that will be a WebSocket Server and that will keep outgoing connections with users and be able to bridge the incomming messages and outgoing ones based on a custom protocol. The drawback is that i need to implement a pub/sub system (or find a solution for). I didn't dig a lot into it but it looks like a lot of work and a homemade solution, i'm not a fan of it.

I didn't find articles that give feedback after exposing such an architecture and websockets in production, i was hoping to find some here.

Answer 1

I agree with you that a simple proxy solution seems to be inadequate as it exposes the internal interfaces to the clients. I found two articles which I think are addressing your problem:

The API Gateway Pattern

Pattern: API Gateway / Backends for Frontends

Both talk about the issues that you have already mentioned in your question: Protocol translation is an advantage of this architecture as it decouples the external API from the protocols internally used. On the other hand, increased complexity due to having another component to be maintained is mentioned as a drawback.

The second article also suggests some existing libraries (namley Netty, Spring Reactor, NodeJS) that can be used to implement an API gateway, so you might want to spend some time evaluating these for your project.