WebSockets & Realtime Systems Programming · Lekcja

Server-Sent Events (SSE) — powtórka

Ponownie oceń SSE pod kątem jednokierunkowego przesyłania danych z serwera do klienta i porównaj je z WebSockets dla konkretnych zastosowań.

Lekcja 2 z 412 kroki

Server-Sent Events (SSE) — powtórka to bezpłatna lekcja WebSockets & Realtime Systems Programming na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej WebSockets & Realtime Systems Programming, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs WebSockets & Realtime Systems Programming zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

Revisiting Server-Sent Events

Welcome back to Server-Sent Events (SSE)! While we briefly touched upon SSE earlier, this lesson dives deeper into its unique strengths and optimal use cases in modern realtime web development.

In a world dominated by WebSockets for full-duplex communication, SSE holds its ground for specific scenarios where a simpler, unidirectional stream is all you need.

SSE: Server-to-Client Only

The fundamental principle of SSE is its unidirectional nature. It allows a server to push updates to a client over a single, persistent HTTP connection.

Data flows only from the server to the client.
Clients cannot send messages back to the server using the same SSE connection.
This simplicity makes it ideal for broadcast-style updates.

Why Choose SSE? Key Benefits

SSE offers several advantages, especially when compared to constantly polling a server:

Simplicity: Built on HTTP, easier to implement than WebSockets for simple pushes.
Automatic Reconnection: Browsers handle reconnects automatically if the connection drops.
Event IDs: Built-in mechanism to track the last received event, preventing data loss.
Browser Native: Uses the standard EventSource API, no complex libraries needed.

SSE vs. WebSockets: Unidirectional vs. Bidirectional

This is the crucial distinction:

SSE: Best for scenarios where the client only needs to receive updates (e.g., news feeds, stock prices). It's like a radio broadcast.
WebSockets: Essential for interactive applications where clients and servers need to send and receive messages freely (e.g., chat apps, online gaming). It's like a phone call.

Choosing between them depends purely on your application's communication needs.

Use Case: Realtime Data Feeds

Consider applications that display live, constantly updating information. These are perfect candidates for SSE:

Stock Tickers: Displaying real-time changes in stock prices.
News Feeds: Pushing new headlines or articles as they're published.
Sports Scores: Instant updates on game scores or events.

The client just listens; it doesn't need to send anything back to initiate updates.

Use Case: Notifications and Progress

Another strong use case for SSE is delivering non-interactive notifications or tracking progress:

User Notifications: "You have a new message!" or "Your friend liked your post."
Background Job Progress: Showing the status of a long-running server task (e.g., "File upload 50% complete").

These scenarios benefit from the server pushing updates without client request, and the client doesn't need to respond.

Building an SSE Server (Node.js)

Here's a simple Node.js example using Express to create an SSE endpoint. Notice the Content-Type header, crucial for SSE.

Try running this example:

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

app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');
  res.flushHeaders(); // Flush headers to establish connection

  let counter = 0;
  const intervalId = setInterval(() => {
    counter++;
    res.write(`data: Server time: ${new Date().toLocaleTimeString()}, count: ${counter}\n\n`);
    if (counter >= 5) {
      res.end(); // End connection after 5 messages
      clearInterval(intervalId);
    }
  }, 1000);

  req.on('close', () => {
    console.log('Client disconnected');
    clearInterval(intervalId);
  });
});

app.get('/', (req, res) => {
  res.send('<p>Go to <a href="/events">/events</a> to see SSE stream.</p><script>const eventSource = new EventSource("/events"); eventSource.onmessage = function(event) { console.log(event.data); document.body.innerHTML += `<p>${event.data}</p>`; }; eventSource.onerror = function(error) { console.error("SSE Error:", error); };</script>');
});

app.listen(PORT, () => {
  console.log(`SSE server listening on port ${PORT}`);
});

Consuming SSE in the Browser

On the client side, consuming SSE is straightforward using the native EventSource API. No special libraries are needed!

This JavaScript snippet shows how to connect and handle incoming messages:

const eventSource = new EventSource('/my-sse-endpoint');

eventSource.onmessage = function(event) {
  console.log("Data received:", event.data);
  // event.data contains the message payload
  // event.lastEventId contains the ID of the last event
};

eventSource.addEventListener('myCustomEvent', function(event) {
  console.log("Custom event received:", event.data);
});

eventSource.onopen = function() {
  console.log("SSE connection established.");
};

eventSource.onerror = function() {
  console.error("SSE connection error or closed.");
  if (eventSource.readyState === EventSource.CLOSED) {
    console.log("Connection closed. Browser will try to reconnect.");
  }
};

// To manually close the connection
// eventSource.close();

Understanding SSE's Limitations

While powerful for its niche, SSE isn't a silver bullet. Be aware of its limitations:

No Bidirectional Communication: Clients cannot send data back to the server over the SSE connection. For that, you need a separate HTTP request or WebSockets.
Text-Only Data: SSE natively supports only UTF-8 encoded text data. Binary data requires encoding (e.g., Base64), adding overhead.
Connection Limits: Browsers typically limit the number of concurrent HTTP connections (usually 6-8 per domain), which applies to SSE.

Event IDs and Automatic Reconnects

EventSource offers built-in features for robustness:

Last-Event-ID: If the connection drops, the browser automatically includes the Last-Event-ID header in the reconnection request. The server can use this to send only missed events.
Automatic Reconnection: The browser automatically attempts to reconnect to the SSE endpoint if the connection is lost. The server can also suggest a retry interval using retry: field.

These features greatly simplify error handling compared to polling.

SSE Quick Check

Considering the core functionalities, which statement best describes Server-Sent Events (SSE)?

Odpowiedz w interaktywnej lekcji

SSE Revisited: Recap

In this lesson, we revisited Server-Sent Events (SSE), understanding its distinct role in realtime web applications.

SSE is ideal for unidirectional server-to-client streaming, perfect for live feeds and notifications.
It's simpler to implement than WebSockets for push-only scenarios, offering automatic reconnection and event IDs.
Remember its limitations: no client-to-server communication and text-only data.

Choose SSE when you only need the server to broadcast updates to clients, keeping your architecture lean and efficient.

Bezpłatny start

Ucz się WebSockets & Realtime Systems Programming dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 12
Lekcje: 47

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Server-Sent Events (SSE) — powtórka” jest bezpłatna?

Tak — pełny tekst „Server-Sent Events (SSE) — powtórka” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu WebSockets & Realtime Systems Programming, przejdź na CoddyKit PRO. Kurs WebSockets & Realtime Systems Programming zawiera 4 lekcji w sumie.

Co nauczysz się w „Server-Sent Events (SSE) — powtórka”?

Ponownie oceń SSE pod kątem jednokierunkowego przesyłania danych z serwera do klienta i porównaj je z WebSockets dla konkretnych zastosowań. Ćwiczysz WebSockets & Realtime Systems Programming z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć WebSockets & Realtime Systems Programming?

Nie wymagamy żadnego doświadczenia. WebSockets & Realtime Systems Programming w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Server-Sent Events (SSE) — powtórka”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji WebSockets & Realtime Systems Programming?

Tak. Każda lekcja WebSockets & Realtime Systems Programming zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

WebTransport i kanały danych WebRTC
Server-Sent Events (SSE) — powtórka
Przyszłość webowych interfejsów API czasu rzeczywistego
Edge computing i czas rzeczywisty na brzegu sieci

← Powrót do WebSockets & Realtime Systems Programming