Long polling and Server-Sent Events in HLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to start a long polling request from the client.

HLD

function startLongPolling() {
  fetch('/events')
    .then(response => response.[1]())
    .then(data => {
      console.log('Received:', data);
      startLongPolling();
    });
}

Drag options to blanks, or click blank then click option'

AarrayBuffer

Bjson

Cblob

Dtext

Attempts:

3 left

💡 Hint

Common Mistakes

Using json() when the server sends plain text.

Not calling the function recursively to continue polling.

The long polling response is usually plain text or JSON. Using text() reads the response as plain text, which is common for long polling.

2fill in blank

medium

Complete the server-side pseudo-code to send an SSE event.

HLD

function sendSSE(response, data) {
  response.write('data: ' + [1] + '\n\n');
}

Drag options to blanks, or click blank then click option'

Adata

BJSON.stringify(data)

Cdata.toString()

DString(data)

Attempts:

3 left

💡 Hint

Common Mistakes

Sending raw objects without stringifying.

Missing the double newline to end the event.

Server-Sent Events send data as text lines. Using JSON.stringify(data) ensures complex data is sent as a JSON string.

3fill in blank

hard

Fix the error in the SSE client code to properly listen for messages.

HLD

const evtSource = new EventSource('/events');
evtSource.[1] = function(event) {
  console.log('Message:', event.data);
};

Drag options to blanks, or click blank then click option'

Aonerror

Bonopen

Conmessage

Donconnect

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'onopen' which fires when connection opens, not for messages.

Using 'onerror' which fires on errors, not messages.

The onmessage event handler listens for incoming SSE messages.

4fill in blank

hard

Fill both blanks to complete the long polling server logic that waits for new data before responding.

HLD

function handleLongPolling(request, response) {
  waitForNewData(() => {
    response.writeHead(200, { 'Content-Type': 'text/plain' });
    response.[1](newData);
    response.[2]();
  });
}

Drag options to blanks, or click blank then click option'

Aend

Bwrite

Csend

Dflush

Attempts:

3 left

💡 Hint

Common Mistakes

Calling end() before write(), causing no data sent.

Using send() which is not a standard Node.js response method.

The server writes the new data with write() and then ends the response with end() to complete the request.

5fill in blank

hard

Fill all three blanks to complete the SSE server setup with correct headers and keep-alive logic.

HLD

function setupSSE(response) {
  response.writeHead(200, {
    'Content-Type': [1],
    'Cache-Control': [2],
    'Connection': [3]
  });
}

Drag options to blanks, or click blank then click option'

A'text/event-stream'

B'no-cache'

C'keep-alive'

D'application/json'

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'application/json' as Content-Type for SSE.

Omitting Cache-Control header causing caching issues.

Not setting Connection to keep-alive causing connection close.

SSE requires Content-Type as text/event-stream, disables caching with no-cache, and keeps the connection alive with keep-alive.

Practice

1. What is the main difference between long polling and Server-Sent Events (SSE)?

easy

A. Long polling closes the connection after each response; SSE keeps the connection open.

B. Long polling uses WebSockets; SSE uses HTTP/2 only.

C. Long polling requires client to open multiple connections; SSE uses multiple connections.

D. Long polling pushes data continuously; SSE waits for client requests.

Solution

1. Step 1: Understand long polling behavior

   Long polling keeps the HTTP request open until the server has data, then closes it after sending the response.

2. Step 2: Understand SSE behavior

   SSE keeps a single HTTP connection open to continuously push updates without closing it.

3. Final Answer:

   Long polling closes the connection after each response; SSE keeps the connection open. -> Option A

4. Quick Check:

   Connection persistence = A [OK]

Hint: Remember: long polling reconnects, SSE stays connected [OK]

Common Mistakes:

• Confusing SSE with WebSockets
• Thinking SSE uses multiple connections
• Believing long polling pushes continuously

2. Which HTTP method is typically used by clients to initiate a Server-Sent Events connection?

easy

A. POST

B. GET

C. PUT

D. DELETE

Solution

1. Step 1: Identify HTTP method for SSE

   SSE connections are initiated by clients using the GET method to request a stream from the server.

2. Step 2: Confirm other methods are not used

   POST, PUT, DELETE are used for data modification, not for opening SSE streams.

3. Final Answer:

   GET -> Option B

4. Quick Check:

   SSE connection method = GET [OK]

Hint: SSE uses GET to open a streaming connection [OK]

Common Mistakes:

• Choosing POST because it sends data
• Confusing PUT or DELETE with SSE initiation
• Thinking SSE uses WebSocket handshake methods

3. Consider this simplified server behavior for long polling:

while True:
  wait_for_event()
  send_response_to_client()
  client_reconnects()

What is the main downside of this approach compared to SSE?

medium

A. It cannot send data to multiple clients simultaneously.

B. It keeps the connection open indefinitely, wasting server resources.

C. It uses UDP instead of TCP, causing unreliable delivery.

D. It requires the client to repeatedly reconnect, causing overhead.

Solution

1. Step 1: Analyze long polling loop

   The server waits for an event, sends a response, then the client reconnects to wait again.

2. Step 2: Identify overhead caused by reconnects

   Each reconnect requires new HTTP handshake, increasing latency and server load.

3. Final Answer:

   It requires the client to repeatedly reconnect, causing overhead. -> Option D

4. Quick Check:

   Repeated reconnects = overhead [OK]

Hint: Long polling reconnects cause overhead, SSE keeps one open [OK]

Common Mistakes:

• Thinking long polling keeps connection open indefinitely
• Confusing TCP/UDP protocols in HTTP context
• Assuming long polling can't handle multiple clients

4. A developer implements SSE but notices the client stops receiving updates after some time. What is a likely cause?

medium

A. The client is not reconnecting after each message.

B. The client is sending multiple GET requests simultaneously.

C. The server is closing the connection prematurely.

D. The server is using POST instead of GET for SSE.

Solution

1. Step 1: Understand SSE connection behavior

   SSE expects the server to keep the connection open to push updates continuously.

2. Step 2: Identify issue with connection closing

   If the server closes the connection early, the client stops receiving updates until it reconnects.

3. Final Answer:

   The server is closing the connection prematurely. -> Option C

4. Quick Check:

   Connection closed early = no updates [OK]

Hint: SSE needs server to keep connection open, not close early [OK]

Common Mistakes:

• Thinking client must reconnect after every message
• Confusing HTTP methods for SSE
• Assuming multiple GET requests improve SSE

5. You are designing a chat app that must support thousands of users receiving real-time messages. Which approach is best and why?
A) Use long polling for all clients.
B) Use Server-Sent Events for all clients.
C) Use WebSockets for all clients.
D) Use HTTP polling every 5 seconds.

hard

A. WebSockets provide full-duplex communication, best for chat scalability.

B. Long polling scales well and reduces server load compared to SSE.

C. SSE keeps one connection per client open, efficiently pushing updates.

D. HTTP polling every 5 seconds is the most real-time and efficient.

Solution

1. Step 1: Evaluate long polling and SSE for scale

   Long polling causes overhead reconnects; SSE keeps connections open but is unidirectional.

2. Step 2: Consider WebSockets for chat

   WebSockets allow two-way communication with a single persistent connection, ideal for chat apps.

3. Step 3: Assess HTTP polling

   Polling every 5 seconds causes high latency and unnecessary load.

4. Final Answer:

   WebSockets provide full-duplex communication, best for chat scalability. -> Option A

5. Quick Check:

   Best real-time chat = WebSockets [OK]

Hint: Chat needs two-way, low-latency: choose WebSockets [OK]

Common Mistakes:

• Choosing SSE for two-way chat communication
• Thinking polling is efficient for real-time
• Assuming long polling scales better than WebSockets