#Microservices and WebSocket

14 messages · Page 1 of 1 (latest)

sinful anchor
#

Hello, I have a question, I am starting in the architecture of Microservices and I have the question of whether or not to manage a WebSocket I should create a dedicated microservice. My doubt arises because from what I understand, Microservices are disposable due to their possible replicas depending on the load.

Should the API-Gateway be the one who handles the socket? I don’t like that idea very much but you know more than I do, I appreciate any information!

spare mirage
#

So, assuming the websocket is for your clients' (as in end-users') connectivity to the system, then yes, you'd want an API Gateway server (or servers) that handles the websocket connections. They would be the "front-door" to the rest of your system. Why don't you like this idea?

sinful anchor
#

Ok, I understand the logic of being the front-door, and it is quite understandable but my doubt arises as to whether it is really the role of the api gateway or not, since I need to manage notification and chat issues.

Or as you mention, should the socket go in the api gateway and the Microservices of chats and notifications listen to it independently?

spare mirage
#

The gateway would be fanning out the requests coming via the websockets to your microservices.

sinful anchor
#

So, where will the sockets themselves be configured to achieve what you tell me should be in a separate Nest project, or within the Nest “api-gateway” project?

spare mirage
#

What do you mean by "configured"?

sinful anchor
#

Let’s see, I understand that it can be done in the api-gateway (which has been a Nest project) without problems, I know. But my question is whether it is the best option to do it. Because I must configure the socket for different processes such as real-time notifications, push notifications and chat topics.

So... It is not clear to me if it is okay to do it in the api-gateway that the only thing it does is redirect my requests to the corresponding Microservices, or on the contrary I should create a separate microservice specifically for communication through the socket.

spare mirage
#

Your wording is very vague. When you say "best option to do it", what does "it" mean? What do you mean by "configure the socket"? With Nest, you can create a particular gateway (class), and then subscribe to messages as (class) methods. Those methods then "speak" to your (micro-)services either also as an event-bus-based process or via request/response. Each method, I would imagine, would fulfil your "process" needs. Hard to tell, because I'm not sure what you mean by "configure".

As the name implies, the "gateway" application should be the "front-end" to all your micro-services. This is actually necessary, because otherwise, each microservice would have to have its own connection to the client and websocket connections are well-known to be more resource intensive, both for the client and the network.

spare mirage
#

And, I have to ask again, why microservices? If you don't even understand how a gateway works or if it should front for a group of microservices, that "concern" is so minuscule to actually having to run a microservices architecture. It's like asking if the water in a pool is cold or not, but yet you don't even know how to swim. It just doesn't make sense.

sinful anchor
#

Okay, I understand, I think I should have better understood before the concept of what a microservice itself is and what a Gateway is.

I feel that I understood things better, I consider managing all the socket connections in the API GATEWAY of my application and based on that call through NATS to the microservices that are required.

I think I can continue thanks to your clarification, I will review essential concepts and basic and necessary things to understand and move forward, thank you!

#

I know that there are many ways to achieve what you explained to me, but I would believe that a correct flow would be something like this (if I’m wrong I would appreciate corrections):

  1. The api gateway receives a request to generate a report

  2. The API gateway redirects that request via NATS to the reporting microservice

  3. When the report microservice finishes the report, it issues an event by NATS to notify of the completion of it.

  4. In the api gateway I will be subscribed to that event through the socket client and from then on I can decide what to do with that “notification” that the generation of the report ended

spare mirage
#
  1. In the api gateway I will be subscribed to that event through the socket client

NATS doesn't have sockets. But, if you meant the NATS client, then yes, it would listen to a "report notifications queue" to pickup the report accomplished notification and your gateway would then send the notification on to the connected client, who made the request.

sinful anchor
#

Perfect, thank you very much for the support and solving my doubts