Long-Term Polling & Short-Term Polling & Data Streaming

When you want to run some big process in the background, we can do two things so that the client feels good and has a good experience

Long Term Polling

• The client sends the request.
• The server processes the request, and a good, beautiful loader is shown for the client while the server does the process
• After completing, the server sends back the response.
• Same TCP connection, no changes

Short Term Polling

• The client sends a request, and the server sends back the response with a unique ID.
• The client sends a request to the server asking, "Have you completed it?"
• Meanwhile, the server does the process in the background.
• After completing, the server sends yes, I am done and sends the response.

Trade-offs

• In long-term polling, the client waits for the response, creating a bad UX.
• In short-term polling, the client sends a request to the server continuously, asking "have you completed", which might put a lot of load on the server, on a large scale.

USECASE

Imagine you are going to design a stone-paper-scissors online game application, and you want to know if user-1 has completed the move or not. At that time, user-2 can ask the server if user-1 completed the move or not continuously [short-term polling].

trade-off

• Due to latency issues, this might not be a good option, as in stone-paper-scissors, there is a time gap of only 5 secs for a user to make a move.
• Fix: Using Websockets

Data Streaming

• In this, we try to send bits and pieces of data generated/processed in real-time from the server.
• This is like filling a water bucket mug by mug without filling it fully directly.
• Here, the response comes piece by piece.