Migrating a client from a REST API to a WebSocket one

Question

I'm working on a system that integrates with several third party services via APIs. Those services require authentication.

Usually, the services are implemented as REST APIs using HTTP. My system assumes that the requests made to the third party services are stateless. However, some of them are starting to provide WebSocket APIs as well, and in some cases, they are replacing the REST APIs with WebSocket ones. I'm not sure that my system's assumption about the requests being stateless is valid anymore.

With the REST APIs, my architecture considers that my calls to the third party services are stateless, since the authentication is handled by a token sent with every request. The architecture looks like this:

my system -> my stateless service wrapper -> HTTP REST -> third party service

When dealing with WebSockets, the authentication step will be done every time that I connect to the service, which feels wrong to me.

I'm considering using the following architecture instead, which tries to :

my system -> HTTP REST -> my stateful service wrapper -> WebSocket -> third party service

With this new architecture, I will keep a session open as much as I can, and my system will still work under the assumption that its requests are stateless. However, now I have to deal with a new internal service, which is my stateful wrapper sitting between my system and the WebSocket endpoint.

Since I'm new to WebSockets, I might be missing something here. Is my approach good enough? If not, what would you change in it?

Answer 1

Background-process not microservice

The consumption of data from a third-party WebSocket service should be treated as a single background-task, not a microservice that can be initiated by HTTP call from time to time.

Your system needs to maintain 1 running instance of a background process that connects to the third-party websocket and acts on data arriving.

If the background process is closed or fails, it needs to simply be restarted.

---

The above should be valid for a Forex live-data feed example. However, if it was a more mixed-scenario, then is should still be treated as a background-process.

If you needed to "send" a Forex trade on that same WebSocket from time to time, you still need to maintain only a single Background Process.

You have several options for choosing mechanisms to get the data to the background process:

• Queue: RabbitMQ, Kafka, etc.. - where the Background Process has a subscription
• Table: In your database - where new trades are added to a table, and the Background Process is signalled by the database when that table is changed.
• and probably more.