Long polling as fallback in Node.js - Mini Project: Build & Apply

Long Polling as Fallback in Node.js

📖 Scenario: You are building a simple chat server that tries to use WebSocket for real-time messages. But if WebSocket is not available, it should use long polling as a fallback to keep the chat messages updated.

🎯 Goal: Create a Node.js server that supports long polling as a fallback method for clients to receive messages when WebSocket is not available.

📋 What You'll Learn

Create a message store array called messages with initial messages

Create a variable called lastMessageId to track the last message ID sent

Implement a long polling route /poll that waits for new messages

Complete the server setup to listen on port 3000

💡 Why This Matters

🌍 Real World

Long polling is used in chat apps and real-time notifications when WebSocket is not supported or blocked by firewalls.

💼 Career

Understanding fallback techniques like long polling helps backend developers build reliable real-time features that work across different network conditions.

1

Create initial message store

Create an array called messages with these exact objects: { id: 1, text: 'Hello' } and { id: 2, text: 'Welcome' }.

Node.js

// Create an array called messages with two message objects
// Your code here

Hint

Use const messages = [ ... ] to create the array with two objects.

2

Add lastMessageId variable

Create a variable called lastMessageId and set it to the id of the last message in the messages array.

Node.js

const messages = [
  { id: 1, text: 'Hello' },
  { id: 2, text: 'Welcome' }
];

// Create lastMessageId variable here
// Your code here

Hint

Use messages[messages.length - 1].id to get the last message's id.

3

Implement long polling route

Using Express, create a GET route at /poll that accepts a query parameter lastId. Inside the route, use a setInterval to check every 1 second if there are new messages with id greater than lastId. When new messages exist, respond with JSON containing those messages and clear the interval.

Node.js

const messages = [
  { id: 1, text: 'Hello' },
  { id: 2, text: 'Welcome' }
];

let lastMessageId = messages[messages.length - 1].id;

const express = require('express');
const app = express();

// Create GET /poll route with long polling logic
// Your code here

Hint

Use app.get('/poll', (req, res) => { ... }) and inside use setInterval to check for new messages.

4

Start the server

Add code to make the Express app listen on port 3000 and log 'Server running on port 3000' when it starts.

Node.js

const messages = [
  { id: 1, text: 'Hello' },
  { id: 2, text: 'Welcome' }
];

let lastMessageId = messages[messages.length - 1].id;

const express = require('express');
const app = express();

app.get('/poll', (req, res) => {
  const lastId = Number(req.query.lastId) || 0;
  const interval = setInterval(() => {
    const newMessages = messages.filter(m => m.id > lastId);
    if (newMessages.length > 0) {
      clearInterval(interval);
      res.json(newMessages);
    }
  }, 1000);
});

// Start server on port 3000
// Your code here

Hint

Use app.listen(3000, () => { console.log('Server running on port 3000') }) to start the server.

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