Websocket architecture implementation in Captain App Backend

HTTP Architecture of Captain App Backend (Before WebSocket Implementation)

Before integrating WebSocket, the Captain App backend relied solely on HTTP for communication between clients and the server. However, since HTTP is a stateless protocol, it introduced delays in requests and responses.

Challenges with HTTP-Based Communication:

1. Lack of Real-Time Updates – Orders were sometimes not reflected instantly in the Kitchen Display System (KDS) and POS (Point of Sale).
2. Inconsistent Data Across Devices – Due to HTTP’s stateless nature, maintaining consistency across all connected devices (Waiters' Go Serve App, KDS, and POS) was difficult.
3. Inefficient Polling System – To fetch updates, KDS and POS used polling, which called the /get_all_shop_tables (GET) API every 5 seconds. This method was inefficient and often caused delays and inconsistent order data.

---

How Captain App Backend Worked with HTTP

1. Waiters Taking Orders:

   • Waiters using the Go Serve App would take customer orders and send them to the server using the /update (POST) method.
   • Any privileged operations like sending orders or checking out tables also used the same /update (POST) endpoint.

2. Polling System for Updates:

   • Since HTTP lacks real-time capabilities, KDS and POS couldn’t receive orders instantly.
   • To fetch updates, they relied on a polling system, calling the /get_all_shop_tables (GET) API every 5 seconds.
   • This method caused delays, extra server load, and inconsistent order synchronization across devices.

---

WebSocket Integration with Captain App Backend

To solve these issues, WebSocket was integrated alongside HTTP, creating an HTTP + WebSocket server.

Why WebSocket?

✅ Real-Time Communication – Unlike HTTP, WebSocket is a stateful protocol that maintains an active connection, enabling instant updates.

✅ Efficient Event-Driven System – Instead of polling, WebSockets trigger real-time events only when needed, reducing server load.

✅ Consistent Data Across Clients – All connected clients (Go Serve App, KDS, POS) receive updates instantly, ensuring data accuracy.

WebSocket Implementation Strategy

1. Instead of replacing HTTP, WebSockets were integrated while keeping existing HTTP operations intact.
2. A WebSocket event handler was introduced to replace polling:
   • The /update (POST) method now acts as the trigger/event.
   • When a waiter places an order or checks out a table, the server broadcasts updates to all connected clients via WebSocket.
   • This eliminates the need for polling and ensures real-time order synchronization across devices.

---

Example Workflow

Connected Clients:

✅ Go Serve App (Waiter 1, 2, 3)

✅ Kitchen Display System (KDS)

✅ Web/Android POS

Total WebSocket Connections: 5 Clients

Scenario: A waiter (Go Serve App) takes an order

1. Waiter 1 takes an order and sends it to the server via /update (POST).
2. The WebSocket event handler in the server detects the update.
3. The server broadcasts the update to all connected clients (other waiters, KDS, and POS) using WebSocket.
4. Within seconds, all clients receive the real-time order update, ensuring instant synchronization.

---

Benefits of WebSocket Integration

🚀 Instant Order Updates – Orders reflect immediately across KDS, POS, and all waiters’ devices.

⚡ No More Polling – Eliminates inefficient GET requests every 5 seconds, reducing server load.

📡 Real-Time Communication – Ensures accurate and synchronized order management across all connected devices.

💡 Better Performance – Less network congestion and faster data transmission.