WebSockets & Realtime Systems Programming · บทเรียน

ทบทวน Server-Sent Events (SSE)

ประเมิน SSE อีกครั้งสำหรับการสตรีมแบบทิศทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์ และเปรียบเทียบกับ WebSockets สำหรับกรณีใช้งานเฉพาะ

บทเรียน 2 จาก 412 ขั้นตอน

ทบทวน Server-Sent Events (SSE) เป็นบทเรียน WebSockets & Realtime Systems Programming ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน WebSockets & Realtime Systems Programming และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส WebSockets & Realtime Systems Programming มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

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)?

ตอบคำถามในบทเรียนแบบโต้ตอบ

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.

เริ่มต้นได้ฟรี

เรียนรู้ WebSockets & Realtime Systems Programming ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 12
บทเรียน: 47

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

คำถามที่พบบ่อย

บทเรียน “ทบทวน Server-Sent Events (SSE)” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “ทบทวน Server-Sent Events (SSE)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส WebSockets & Realtime Systems Programming ให้อัปเกรดเป็น CoddyKit PRO คอร์ส WebSockets & Realtime Systems Programming มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “ทบทวน Server-Sent Events (SSE)”

ประเมิน SSE อีกครั้งสำหรับการสตรีมแบบทิศทางเดียวจากเซิร์ฟเวอร์ไปยังไคลเอนต์ และเปรียบเทียบกับ WebSockets สำหรับกรณีใช้งานเฉพาะ คุณปฏิบัติ WebSockets & Realtime Systems Programming ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน WebSockets & Realtime Systems Programming หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน WebSockets & Realtime Systems Programming บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “ทบทวน Server-Sent Events (SSE)” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน WebSockets & Realtime Systems Programming นี้ได้ไหม

ได้ บทเรียน WebSockets & Realtime Systems Programming ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ WebSockets & Realtime Systems Programming