Server-Sent Events (SSE) is a technology for efficiently pushing real-time updates from the server to the client over a single, long-lived HTTP connection. This method is especially useful for applications that require real-time notifications or continuous data updates, such as live sports scores, chat applications, or log streaming applications.
How Server-Sent Events Work
SSE leverages the HTTP protocol to keep a persistent connection between the server and the client. Unlike WebSockets, which allow for two-way communication, SSE is designed for unidirectional communication, where the server sends updates to the client. Here’s how it works:
- Client Request: The client establishes a connection to the server by making a GET request to a specific endpoint.
- Persistent Connection: The server keeps this connection open and sends updates to the client as they become available.
- Event Stream: Updates are sent in the form of events, which can be simple messages or more structured data.
Advantages of SSE
- Simplicity: SSE uses standard HTTP, making it easy to implement and compatible with existing web infrastructure.
- Automatic Reconnection: The browser’s built-in
EventSource
API automatically handles reconnection if the connection is lost. - Efficient for Unidirectional Updates: Ideal for scenarios where only the server needs to push updates to the client.
Comparison with Other Protocols
SSE vs. WebSockets
- Use Case: SSE is best suited for applications where the server needs to push updates to the client, but the client does not need to send messages back to the server frequently. WebSockets, on the other hand, are ideal for real-time, bi-directional communication, such as in chat applications.
- Implementation: SSE is easier to implement since it uses HTTP and requires no additional protocols. WebSockets require establishing a new protocol connection over HTTP.
- Browser Support: Both SSE and WebSockets are well-supported across modern browsers. However, SSE benefits from being more straightforward due to its use of HTTP.
SSE vs. Long Polling
- Efficiency: SSE maintains a single connection, making it more efficient than long polling, which involves repeated HTTP requests.
- Complexity: SSE is simpler to implement than long polling, which requires managing repeated requests and responses.
Using Server-Sent Events
Developing a web application that uses server-sent events is straightforward. You’ll need a bit of code on the server to stream events to the front-end, but the client-side code works almost identically to WebSockets in part of handling incoming events. This is a one-way connection, so you can’t send events from a client to a server.
Creating an EventSource Instance
To open a connection to the server to begin receiving events from it, create a new EventSource
object with the URL of a script that generates the events. For example:
const evtSource = new EventSource("/api/logs/filename.log");
Listening for Message Events
Messages sent from the server that don’t have an event field are received as message events. To receive message events, attach a handler for the message event:
evtSource.onmessage = (event) => {
console.log(`Message: ${event.data}`);
};
Listening for Custom Events
Messages from the server that do have an event field defined are received as events with the name given in the event. For example:
evtSource.addEventListener("ping", (event) => {
console.log(`Ping at ${event.data}`);
});
Error Handling
When problems occur (such as a network timeout or issues pertaining to access control), an error event is generated. You can take action on this programmatically by implementing the onerror
callback on the EventSource
object:
evtSource.onerror = (err) => {
console.error("EventSource failed:", err);
};
Closing Event Streams
By default, if the connection between the client and server closes, the connection is restarted. The connection is terminated with the .close()
method.
evtSource.close();
Practical Applications of SSE
Possible Applications
Server-Sent Events are suitable for a variety of applications where real-time updates from the server are needed. Here are a few examples:
- Real-Time Charts: Streaming stock prices or other financial data.
- Live News Coverage: Posting links, tweets, and images during an event.
- Live Social Media Feeds: A live Twitter wall fed by Twitter’s streaming API.
- Server Monitoring: Monitoring server statistics like uptime, health, and running processes.
Example: Log Streaming Application
To illustrate how SSE works, let’s consider a log streaming application. This application, built with React for the frontend and Go for the backend, allows users to stream multiple log files dynamically, view them in a single window, and close individual streams. The complete implementation is available on GitHub. Below, I’ll provide a detailed explanation with essential code snippets to help you understand the setup.
Frontend (React)
In the frontend, we use React to create a user interface that allows selecting log files to stream and displays the logs in real-time.
Initial Setup
First, we fetch the list of available log files when the component mounts:
import React, { useEffect, useState, useRef } from 'react';
import './App.css';
function App() {
const [logFiles, setLogFiles] = useState([]);
const [selectedFile, setSelectedFile] = useState('');
const [logs, setLogs] = useState({});
const [streaming, setStreaming] = useState({});
const eventSourceRefs = useRef({});
useEffect(() => {
fetch('/api/files')
.then(response => response.json())
.then(data => setLogFiles(data.files))
.catch(error => console.error('Error fetching files:', error));
}, []);
// Other functions and return statement
}
Starting and Stopping the Log Stream
We define functions to start and stop streaming logs for the selected file using the EventSource
API:
const startStreaming = () => {
if (!selectedFile || streaming[selectedFile]) return;
const eventSource = new EventSource(`/api/logs/${selectedFile}`);
eventSourceRefs.current[selectedFile] = eventSource;
setStreaming(prevState => ({ ...prevState, [selectedFile]: true }));
eventSource.onmessage = function(event) {
setLogs(prevLogs => ({
...prevLogs,
[selectedFile]: [...(prevLogs[selectedFile] || []), event.data],
}));
};
eventSource.onerror = function() {
eventSource.close();
setStreaming(prevState => ({ ...prevState, [selectedFile]: false }));
};
};
const stopStreaming = () => {
if (eventSourceRefs.current[selectedFile]) {
eventSourceRefs.current[selectedFile].close();
setStreaming(prevState => ({ ...prevState, [selectedFile]: false }));
}
};
Rendering the Logs
Finally, we render the logs in the component and provide controls to start and stop streaming:
return (
<div className="App">
<header className="App-header">
<div className="controls">
<select onChange={(e) => setSelectedFile(e.target.value)} value={selectedFile}>
<option value="">Select a log file</option>
{logFiles.map(file => (
<option key={file} value={file}>{file}</option>
))}
</select>
<button onClick={startStreaming} disabled={!selectedFile || streaming[selectedFile]}>
{streaming[selectedFile] ? 'Streaming...' : 'Start Streaming'}
</button>
<button onClick={stopStreaming} disabled={!streaming[selectedFile]}>
Stop Streaming
</button>
</div>
<div className="logs-container">
{(logs[selectedFile] || []).map((log, index) => (
<div key={index} className="log-entry">{log}</div>
))}
</div>
</header>
</div>
);
Backend (Go)
The backend, built with Go and the Gin framework, serves the log files and streams the log data to the client using SSE.
Setting Up the Server
First, we set up the Gin router and define endpoints for listing log files and streaming logs:
package main
import (
"bufio"
"fmt"
"net/http"
"os"
"strings"
"github.com/gin-gonic/gin"
)
func main() {
router := gin.Default()
router.GET("/api/files", listLogFiles)
router.GET("/api/logs/:filename", streamLogFile)
router.Run(":8080")
}
func listLogFiles(c *gin.Context) {
files, err := os.ReadDir("/tmp/local")
if err != nil {
c.String(http.StatusInternalServerError, "Error reading directory")
return
}
var logFiles []string
for _, file := range files {
if strings.HasSuffix(file.Name(), ".log") {
logFiles = append(logFiles, file.Name())
}
}
c.JSON(http.StatusOK, gin.H{"files": logFiles})
}
Streaming Log Files
Next, we implement the function to stream log files using SSE:
func streamLogFile(c *gin.Context) {
filename := c.Param("filename")
filePath := fmt.Sprintf("/tmp/local/%s", filename)
file, err := os.Open(filePath)
if err != nil {
c.String(http.StatusNotFound, "File not found")
return
}
defer file.Close()
c.Header("Content-Type", "text/event-stream")
c.Header("Cache-Control", "no-cache")
c.Header("Connection", "keep-alive")
scanner := bufio.NewScanner(file)
for scanner.Scan() {
fmt.Fprintf(c.Writer, "data: %s\n\n", scanner.Text())
c.Writer.Flush()
}
if err := scanner.Err(); err != nil {
c.String(http.StatusInternalServerError, "Error reading file")
}
}
Output
By leveraging SSE, we can efficiently stream log files from the server to the client, providing real-time updates without the need for frequent HTTP requests. This setup ensures a smooth and responsive user experience for monitoring logs or other continuous data streams.
For the complete implementation and further details, you can check the Log Streaming Application on GitHub.
Conclusion
Server-Sent Events provide a simple and effective way to push real-time updates from the server to the client. This technology is especially useful for applications like log streaming, where real-time updates are crucial. By using SSE, you can build applications that are both efficient and easy to maintain, leveraging standard HTTP connections and built-in browser support.
For more information and detailed specifications, you can refer to:
By understanding and implementing SSE, developers can create robust real-time applications that efficiently manage server-to-client communication. Whether you are monitoring stock prices, live news, or server logs, SSE provides a reliable and straightforward approach to real-time data updates.