Can the Same Process Serve Both WebSocket + Http Rquest?

(why is this an important question to ask)

When building the chat app, we want to serve socket traffic to tell when a user is online and have the message be send as socket data package.

The application also have some other functionality such as login/logout. Those are typically served by http protocols. This is because the server has no need to push to client for these features.

We can separte these two functionalities. The web socket can talk to other HTTP services via libray such as Python’s Request.

At the API gateway level, these two types of services can be routed differently.

See this StackOverflow question for more details: https://serverfault.com/questions/575467/running-a-websocket-server-and-a-http-server-on-the-same-server

1. achievable if two process running on to ip
2. if two processes running on same ip but different ports
3. if one process running on same ip and same port but can handle two protocols at the same time. For example flasksocket + flask can achieve this.

Should the Same Process Serve Both WebSocket and Http Traffic?

Depends on if we want to scale these two bakcend differently. If so, we should have SocketServer and Http Server be two separate backend services.

How Should the Http Traffic from the WebSockets be routed?

Should these triffic go through the API gateway again(as if they these internal traffics are from external)?

What is WebSocket?

WebSocket is a protocol allow bi-directional communication between the server and the client.

Server was not able to talk to client when relying on HTTP only.

how to implement websocket client.
how to implement websocket server.

See this link for moe details: https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy

How Does Inter-Backends Communication Work?

We do not really need this for the chat app backend because wo have already introduced a message broker.

Each socket server can dynamically subscribe to topics(keyed by threadid).

What does the desired architecture look like? Why does this version need to have a presence service?

Load balancer connects clients to socket server. Round robin is enough. No need for sticky session. Because inter-backend server communication is facilitated by a message bus. Therefore we need a presence service(canbe hanled by the session state redis cluster). (Alternative architecture need to have each wbsocket server know about other’s exits and perform consistent hashing which no longer needs a dedicated message broker)

Using session to manager user’s auth state. The session state is stored in a redis cluster. The actual credentials are stored in a users table(relational db).

send message to users in a thread that is online:

1. because online users connects to the web socket servers, and the servers subscribes to the message broker topics. This subscriber callback will go over the connected sockets and send the message via the socket connection. The message broker’s queue worker only need to post message to the recepiant queue(keyed by thread_id).

2. send message to users in a thread that is offline The thread queue worker needs to look up all the members in the thread(full picture) and check the session service(sometimes called the presence server) to find out who in the threads are offline.
   For those people offline, this worker need to make an entry in the database. When user getsback online the next time, it will create a task to ask for past message from the thread.