Introduction
We will explore the differences between Short Polling, Long Polling, and WebSockets, detailing how each method facilitates client-server communication, and discussing their respective efficiencies and potential use cases.
Short Polling
How it Works: The client repeatedly sends HTTP requests at regular intervals to a server to check for updates. This is like continually asking, “Is there something new?”
Pros: Simple to implement; works on almost all web servers and clients.
Cons: Inefficient as it involves making frequent requests regardless of whether there are updates, leading to high bandwidth and resource usage.
Sequence:
- Client calls resource at a specified interval
- Client waits for a short time
- Client receive response from the resource
Long Polling
How it Works: The client sends a request to the server, just like in short polling, but the server holds the request open until it has new data to send. Once the data is sent, the client immediately makes another request. Mostly the preferred option while designing REST API; preferred over Short Polling
Pros: Not wasting cycle; more efficient than short polling because updates are sent as soon as they are available, reducing unnecessary data transmission.
Cons: Time of a connection is a waste; can still be inefficient if updates are infrequent and connections remain open. Also, it could cause delays if the timeout is reached without any data.
Sequence:
- Client calls a resource
- If a resource has data then it returns immediately
- However, if the resource doesn’t have the data then it wait for sometime and keep the connection open
- While the connection is active, if data arrives, resource returns the data back to client
- Client need not required to send request again
WebSockets
How it Works: Establishes a full-duplex communication channel that stays open, allowing real-time, bidirectional communication between the client and server. Opens a highway connection between client and resource. The client and server can exchange data at any time without requiring new connections for each transfer.
Pros: Resource is in full control to send data anytime to a client as it fits. Highly efficient and suitable for situations where messages need to be exchanged frequently and with minimal latency.
Cons: Connection remains open all the time; needs security aspects consideration. More complex to implement and requires specific server infrastructure to handle WebSocket connections.
Polling vs WebSockets
Short Polling
Almost always a bad-idea.
Only scenario where short polling can be useful
- Building a prototype
- Very limited number of data continuously needs to be synced or network delay exists.
Long Polling
Good choice mostly
Can scale-up quickly
WebSockets
Good choice for very specific use cases – e.g.,
- Web chat with many users in the chatroom and there is a need to push / exchanges messages between 2 users
- Application requires very low latency
