WebSockets & Realtime Systems Programming · Leçon

Interrogation, interrogation longue et SSE

Comparez les méthodes traditionnelles comme l’interrogation et l’interrogation longue avec les événements envoyés par le serveur pour transmettre des données.

Leçon 2 sur 412 étapes

Interrogation, interrogation longue et SSE est une leçon WebSockets & Realtime Systems Programming gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage WebSockets & Realtime Systems Programming, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours WebSockets & Realtime Systems Programming comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

HTTP's Realtime Challenge

HTTP is stateless and unidirectional: the client asks, the server answers once. For live chat or tickers, constant asking or waiting is inefficient.

Introducing Polling

Polling is the simplest pseudo-realtime trick: the client asks the server for new data on a fixed interval, getting updates or an empty reply each time.

Polling Code Example

Here's a JavaScript client that polls a server every 2 seconds for updates — open your console to watch it fire.

<!DOCTYPE html>
<html>
<head>
  <title>Polling Example</title>
</head>
<body>
  <h1>Polling Status: <span id="status">Waiting...</span></h1>
  <script>
    function fetchData() {
      // In a real app, this would be a server endpoint
      fetch('https://jsonplaceholder.typicode.com/todos/1') 
        .then(response => response.json())
        .then(data => {
          const statusElement = document.getElementById('status');
          statusElement.innerText = `Update at ${new Date().toLocaleTimeString()}`; 
          console.log('Polled:', data.title);
        })
        .catch(error => console.error('Polling error:', error));
    }

    // Poll every 2 seconds (2000 milliseconds)
    setInterval(fetchData, 2000);
    fetchData(); // Initial fetch to start
  </script>
</body>
</html>

Polling's Inefficiency

Polling is wasteful: high latency between polls, many empty responses burning resources, and poor scaling when many clients poll often.

Enter Long Polling

Long polling is smarter: instead of replying empty, the server holds the request open until data is ready or it times out, then the client reconnects.

How Long Polling Works

The long polling cycle: client requests, server waits for data or timeout, server responds and closes, client immediately re-requests to restart.

Long Polling Client Logic

Here's the long polling client pattern: it processes each response, then immediately reopens the connection (retrying after a delay on error).

function longPoll() {
  console.log('Long polling for updates...');
  fetch('/api/longpoll') // Imagine this endpoint holds the request
    .then(response => response.json())
    .then(data => {
      if (data && data.message) {
        console.log('Received update:', data.message);
        // In a real app, update UI here
      } else {
        console.log('No new data, server likely timed out or sent empty.');
      }
      longPoll(); // Immediately send a new request
    })
    .catch(error => {
      console.error('Long polling error:', error);
      // Retry after a delay on error to prevent flooding
      setTimeout(longPoll, 3000); 
    });
}

longPoll(); // Start the long polling process

Long Polling's Pros & Cons

Long polling cuts latency and request count versus plain polling, but it still rides the request-response model — each update sets up and tears down a connection.

Server-Sent Events (SSE)

Server-Sent Events (SSE) give true server push over one long-lived HTTP connection. It's one-way (server to client) — perfect for feeds, tickers, notifications.

SSE Client Example

The native EventSource API makes subscribing to an SSE stream easy — the connection stays open until you close it or an error hits.

<!DOCTYPE html>
<html>
<head>
  <title>SSE Example</title>
</head>
<body>
  <h1>SSE Updates:</h1>
  <ul id="events"></ul>
  <script>
    // Imagine a server at /sse-stream sending events
    const eventSource = new EventSource('https://example.com/sse-stream'); // Replace with a real SSE endpoint

    eventSource.onopen = () => {
      console.log('SSE connection opened.');
      const listItem = document.createElement('li');
      listItem.textContent = `Connection opened at ${new Date().toLocaleTimeString()}`;
      document.getElementById('events').appendChild(listItem);
    };

    eventSource.onmessage = (event) => {
      const listItem = document.createElement('li');
      listItem.textContent = `New message: ${event.data}`;
      document.getElementById('events').appendChild(listItem);
      console.log('Received SSE message:', event.data);
    };

    eventSource.onerror = (error) => {
      console.error('SSE Error:', error);
      const listItem = document.createElement('li');
      listItem.textContent = `Error: ${error.message || 'Unknown'}`;
      document.getElementById('events').appendChild(listItem);
      eventSource.close(); // Close connection on error
    };

    // You can also listen for custom named events:
    // eventSource.addEventListener('myCustomEvent', (event) => {
    //   console.log('Custom event data:', event.data);
    // });
  </script>
</body>
</html>

Quick Check: Compare Methods

Which of the following statements about Polling, Long Polling, and Server-Sent Events (SSE) are true?

Recap: Unidirectional Push

Recap: polling repeatedly asks (simple but wasteful), long polling holds the request open, and SSE pushes one-way over a persistent connection.

Gratuit pour commencer

Apprends WebSockets & Realtime Systems Programming avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours
12
Leçons
47

Questions Fréquemment Posées

La leçon « Interrogation, interrogation longue et SSE » est-elle gratuite ?

Oui — le texte complet de « Interrogation, interrogation longue et SSE » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours WebSockets & Realtime Systems Programming, passe à CoddyKit PRO. Le cours WebSockets & Realtime Systems Programming comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Interrogation, interrogation longue et SSE » ?

Comparez les méthodes traditionnelles comme l’interrogation et l’interrogation longue avec les événements envoyés par le serveur pour transmettre des données. Tu pratiques WebSockets & Realtime Systems Programming avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer WebSockets & Realtime Systems Programming ?

Aucune expérience préalable n'est requise. WebSockets & Realtime Systems Programming sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Interrogation, interrogation longue et SSE » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon WebSockets & Realtime Systems Programming ?

Oui. Chaque leçon WebSockets & Realtime Systems Programming inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Évolution des communications Web
  2. Interrogation, interrogation longue et SSE
  3. Introduction aux WebSockets : une nouvelle ère
  4. Choisir la bonne technologie temps réel
← Retour à WebSockets & Realtime Systems Programming