Long polling as fallback in Node.js - Step-by-Step Execution

Concept Flow - Long polling as fallback

Client sends request

↓

Server holds request open

↓

Event occurs or timeout

↓

Server sends response

↓

Client receives data

↓

Client immediately sends new request

↩Back to Client sends request

The client sends a request that the server keeps open until new data is ready or a timeout happens. Then the server responds, and the client immediately sends another request to keep listening.

Execution Sample

Node.js

app.get('/poll', (req, res) => {
  holdRequestUntilEventOrTimeout(() => {
    res.json({ data: 'new data' });
  });
});

Server holds the GET /poll request until new data is ready or timeout, then responds with JSON.

Execution Table

Step	Client Action	Server State	Server Response	Client Reaction
1	Sends GET /poll	Waiting for event or timeout	No response yet	Waiting
2	Waiting	Event occurs	Sends JSON data	Receives data
3	Sends new GET /poll immediately	Waiting for event or timeout	No response yet	Waiting
4	Waiting	Timeout reached (no event)	Sends empty JSON	Receives empty data
5	Sends new GET /poll immediately	Waiting for event or timeout	No response yet	Waiting
6	Waiting	Event occurs	Sends JSON data	Receives data
7	Stops sending requests	No request received	No response	Stops polling

💡 Client stops sending requests, so server no longer holds connections.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
ClientRequest	None	GET /poll sent	GET /poll sent	GET /poll sent	None (stopped)
ServerHold	No	Yes (holding)	Yes (holding)	Yes (holding)	No
ServerResponse	None	JSON data sent	Empty JSON sent	JSON data sent	None
ClientData	None	Received data	Received empty data	Received data	None

Key Moments - 3 Insights

Why does the client send a new request immediately after receiving data?

Because long polling keeps the connection open only until data is sent or timeout. To keep listening for new data, the client must send a new request as shown in steps 2 and 3 of the execution_table.

What happens if no event occurs before the timeout?

The server sends an empty or timeout response (step 4), so the client knows to send a new request to keep polling, preventing the connection from hanging indefinitely.

Why does the server hold the request open instead of responding immediately?

Holding the request lets the server send data only when new information is available, reducing unnecessary responses and simulating real-time updates as shown in the server state during steps 1 and 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the server state at Step 3?

A No request received

B Waiting for event or timeout

C Sending JSON data

D Timeout reached

💡 Hint

Check the 'Server State' column for Step 3 in the execution_table.

At which step does the client receive empty data due to timeout?

A Step 4

B Step 2

C Step 6

D Step 7

💡 Hint

Look at the 'Server Response' and 'Client Reaction' columns in the execution_table.

If the client stops sending new requests, what happens to the server state?

A Server keeps holding requests

B Server sends continuous responses

C Server has no requests to hold

D Server crashes

💡 Hint

Refer to the 'exit_note' and final rows in the execution_table.

Concept Snapshot

Long polling keeps a client request open until new data or timeout.
Server responds only when ready or timed out.
Client immediately sends a new request after response.
This simulates real-time updates without WebSockets.
Useful as fallback when WebSockets are unavailable.

Full Transcript

Long polling is a technique where the client sends a request to the server, and the server holds this request open until new data is available or a timeout occurs. When the server responds, the client immediately sends another request to keep listening for updates. This cycle continues until the client stops polling. This method helps simulate real-time communication without needing WebSockets. The server state changes from waiting to responding, and the client reacts by sending new requests or stopping. If no event occurs before timeout, the server sends an empty response, prompting the client to send a new request. This ensures the connection does not hang indefinitely.

Practice

1. What is the main purpose of using long polling in Node.js applications?

easy

A. To keep a client request open until new data is available

B. To immediately close the connection after sending data

C. To send multiple responses to a single request

D. To replace WebSocket connections entirely

Solution

1. Step 1: Understand long polling behavior

   Long polling keeps the client request open until the server has new data to send.

2. Step 2: Compare options to this behavior

   Only To keep a client request open until new data is available describes this behavior correctly; others describe different or incorrect behaviors.

3. Final Answer:

   To keep a client request open until new data is available -> Option A

4. Quick Check:

   Long polling = open request until data ready [OK]

Hint: Long polling holds request open until data arrives [OK]

Common Mistakes:

• Thinking long polling sends multiple responses per request
• Confusing long polling with WebSocket persistent connection
• Assuming long polling closes connection immediately

2. Which of the following is the correct way to implement a long polling endpoint in Node.js using Express?

easy

A. res.write('data'); // keep connection open without res.end()

B. res.send('data'); res.end();

C. res.json('data'); res.end();

D. res.send('data'); // then wait before closing connection

Solution

1. Step 1: Identify how to keep connection open

   In long polling, the server holds the connection open, so it should not call res.end() immediately.

2. Step 2: Check which option keeps connection open

   res.write('data'); // keep connection open without res.end() uses res.write() without res.end(), which keeps the connection open for long polling.

3. Final Answer:

   res.write('data'); // keep connection open without res.end() -> Option A

4. Quick Check:

   Keep connection open = no res.end() [OK]

Hint: Use res.write() without res.end() to keep connection open [OK]

Common Mistakes:

• Calling res.end() immediately closes connection
• Using res.send() closes connection right away
• Not sending any response causes timeout

3. Consider this Node.js long polling code snippet:

app.get('/poll', (req, res) => {
  setTimeout(() => {
    res.json({ message: 'Update available' });
  }, 5000);
});

What will the client experience when calling this endpoint?

medium

A. The client never receives a response

B. The client receives the update immediately

C. The client waits 5 seconds, then receives the update

D. The client receives multiple updates every 5 seconds

Solution

1. Step 1: Analyze the setTimeout delay

   The server waits 5 seconds before sending the JSON response.

2. Step 2: Understand client wait behavior

   The client request stays open during the 5 seconds, then receives the update once sent.

3. Final Answer:

   The client waits 5 seconds, then receives the update -> Option C

4. Quick Check:

   setTimeout delay = delayed response [OK]

Hint: setTimeout delays response, client waits that time [OK]

Common Mistakes:

• Assuming immediate response despite delay
• Expecting multiple responses from one request
• Thinking client never gets response

4. Given this long polling code snippet, what is the main issue?

app.get('/poll', (req, res) => {
  res.json({ message: 'Update' });
  setTimeout(() => {
    res.json({ message: 'Another update' });
  }, 3000);
});

medium

A. The first res.json() never sends data

B. Calling res.json() twice causes an error

C. setTimeout is not asynchronous

D. The server never responds to the client

Solution

1. Step 1: Understand res.json() behavior

   res.json() sends a response and closes the connection immediately.

2. Step 2: Analyze calling res.json() twice

   Calling res.json() a second time after the connection is closed causes an error.

3. Final Answer:

   Calling res.json() twice causes an error -> Option B

4. Quick Check:

   Multiple res.json() calls = error [OK]

Hint: Only one res.json() per request allowed [OK]

Common Mistakes:

• Thinking setTimeout blocks code
• Assuming multiple res.json() calls send multiple responses
• Ignoring connection close after first response

5. You want to implement long polling as a fallback in a Node.js app that first tries WebSocket. Which approach correctly handles fallback and client reconnection?

hard

A. Use WebSocket and long polling simultaneously, sending duplicate data to client

B. Use WebSocket only; if unavailable, do nothing and drop updates

C. Use long polling only; never try WebSocket to simplify code

D. Use WebSocket; if unavailable, client repeatedly sends GET requests that wait on server until data or timeout, then reconnect

Solution

1. Step 1: Understand fallback strategy

   WebSocket is preferred for real-time, but fallback uses long polling with repeated client requests.

2. Step 2: Identify correct client reconnection method

   The client must send repeated GET requests that wait on server until data or timeout, then reconnect to keep updates flowing.

3. Final Answer:

   Use WebSocket; if unavailable, client repeatedly sends GET requests that wait on server until data or timeout, then reconnect -> Option D

4. Quick Check:

   Fallback = repeated long polling requests [OK]

Hint: Fallback means repeated long polling requests after WebSocket fails [OK]

Common Mistakes:

• Ignoring fallback and dropping updates
• Sending duplicate data by using both methods simultaneously
• Not reconnecting client after long polling timeout