DEV Community

Say Goodbye to WebSockets? Why SSE Might Be Your New Best Friend

zakaria chahboun on February 11, 2025

Introduction Hey fellow devs! 👋 Today, let's dive into Server-Sent Events (SSE) and explore why they might be your next favorite tool fo...

Read full post

Mike Talbot ⭐ • Feb 11

A warning: you're probably going to still need some kind of polling fallback. These days I check for receipt acknowledgement and then use the SSE stream for polling, which works, but the server has to close the connection if it doesn't get an "ack".

Server Sent Events are still not production ready after a decade. A lesson for me, a warning for you!

Mike Talbot ⭐ ・ Jun 6 '20

#webdev

zakaria chahboun • Feb 12

Cool, thanks for sharing! I will read it. 🙏

KUNDAN KUMAR • Feb 12

True. I am still struggling to configure nginx properly for SSE

Mike Talbot ⭐ • Feb 12

res.set({
        "Content-Type": "text/event-stream",
        "Cache-Control": "no-cache, no-store, must-revalidate",
        Pragma: "no-cache",
        Expires: "0",
        "Transfer-Encoding": "chunked",
        Connection: "keep-alive",
        "Access-Control-Allow-Origin": process.env.ORIGIN || request.get("origin") || "*",
        "X-Accel-Buffering": "no",
    })

These are the headers I send

OssiDev • Feb 11 • Edited

It's amazing that I've been at this for 15+ years and I'm still discovering new things like server-sent events. It was proposed 20 years ago already and somehow I've missed it completely. Simply never bumped into it.

Thanks for this post!

zakaria chahboun • Feb 12

Glad this post brought it to your attention! Do you think you'll use SSE in any of your projects?

Elanza-48 • Feb 12

The title of the post is very misleading. You might get excited when you learn new things that doesn't mean "Saying goodbye to something", just for views don't do such nonsense.

zakaria chahboun • Feb 12

Not everything has to be taken so seriously—sometimes a catchy title is just that. Take it easy!

John Watts • Feb 12

Click bait is always click bait.

Octavio Santi • Feb 12 • Edited

I dont think this will replace the websockets, its just another technology for different use cases. SSE is for one way comunication and is more related to send notifications between the client and the server (for example in my job we have a react app who run inside of a 3rd party old electron app who has our app inside of an iframe and we needed to use SSE for sending an event to revoke all cookies in the electron application). If I need a chat or something "in real time" id still prefer to use web socket, things like push notifications SSE is the best choice

zakaria chahboun • Feb 12

Of course, it's not a replacement because they serve different purposes. But if you want to deal with real-time data, you should consider SSE first. If you need a more complex, duplex channel, then WebSockets are the way to go!

rslhelper • Feb 12

witching from WebSockets to SSE sounds like a big shift! SSE’s simplicity and lower overhead make it a strong alternative, especially for real-time updates. Curious to see how it holds up in high-demand applications!

zakaria chahboun • Feb 12

Try it and tell us 😉

jothish • Feb 12

It's just a brodcaster?
How the authorisation works here?
If there is 100 users , everyone will get everyones data??
I'm sorry I'm just a noob trying new things

zakaria chahboun • Feb 12

Great questions! SSE isn't just a broadcaster—it's a way for the server to push updates to clients in real-time over a single HTTP connection.

As for authorization, it usually works by validating the user's identity before establishing the SSE connection, just like any other secure connection.

// Sends a GET request to /events
const eventSource = new EventSource('/events', {
    headers: {
        'Authorization': 'Bearer your_token_here'
    }
});

// Or Cookies
const eventSource = new EventSource('/events', {
    withCredentials: true // Ensures cookies and credentials are sent with the request
});

The server responds with an HTTP response that has a Content-Type: text/event-stream header and keeps the connection open to send multiple events over time.

Regarding your last question: If you have 100 users, each client will only receive the data that the server sends to it. Typically, you would send specific updates based on the user’s permissions or the data they’re subscribed to, so not everyone gets everyone else's data.

Troy High • Feb 12

@5p4r70n , you would have to use your existing auth model. For example, we use sse to send notifications to users of our system when they are in the admin console. The app uses tokens so the server only receives authenticated messages.

Also since we have info on the user via the token we store some identifier info on the cached connection pool so when a SSE is generated we can send only to clients that match the recipient id.

peerreynders • Feb 12

SSE is simplest described as a regular HTTP request with a streaming response; the streaming payload is events.

The server closing the response is unexpected, so the client sends another request to start again.
The client will close the connection when it is done with the request.

WS requests on the other hand convert (“upgrade”) the HTTP request to something outside of the HTTP spec to get access to the sockets that the original HTTP request was using.

In both cases the server has to manage a distinct connection to each user; however SSE connections tend to be less demanding on server resources and SSE may work where WS won't; like when firewalls block non-HTTP traffic. But both require an always-on server,so neither of them is suitable for a serverless environment.

jothish • Feb 12

Ok, go it

The server and client will keep this connection alive for future server-to-client event notifications.

Thanks! 😊

Naveen Kumar • Feb 12

Few days back, we got a requirement where our DAO layer is collecting data from some files in the backend, as now this data can be large and we cannot load the complete data in memory hence we thought of going with SSE where server can send the data in chunks to Client in stream without loading the complete data.
In this case also SSE played a good role to send the data continuously without waiting to load in memory at once.

Websocket can be also used for this purpose but here we dont want duplex channel hence SSE played a vital role.

zakaria chahboun • Feb 12

Thanks for sharing your experience!

Andrew Rhyand • Feb 12

Using SSE as been a new pattern for me. After using tools like HTMX, I feel in love with sending back fragments of HTML.

Then I found Datastar data-star.dev/

It's a blend of JS signals, HTMX, and SSE.

zakaria chahboun • Feb 12

Have you used it in a real project? I mean "Data star"?

Andrew Rhyand • Feb 12

Internal tools only. It's still in beta with v1 on the horizon.

Daniel T Sasser II • Feb 12

👏

Athreya aka Maneshwar • Feb 12

Pretty solid, btw how did you create the blog image?

zakaria chahboun • Feb 12

Thanks man! For the cover it's just AI generated.

Code With Sushil • Feb 12

thanks man

zakaria chahboun • Feb 12

You're welcome man!

Albi Rental Belitung • Feb 12

thanks

zakaria chahboun • Feb 12

You are welcome!

May Sanders • Feb 12

Server-Sent Events (SSE) can be a game-changer for real-time web applications, especially for use cases like notifications, live updates, and monitoring dashboards. Unlike WebSockets, SSE operates over a single HTTP connection and is inherently more efficient for unidirectional data streaming. However, when integrating SSE with GenAI applications, security risks must be carefully considered. Exposing AI-generated content through SSE could lead to data leakage, injection attacks, or unauthorized access if not properly secured. Implementing authentication, rate limiting, and content validation is essential to mitigate these risks.

Kalapee Gajjar • Feb 12

Okay more seaport to back and

Frozen Forest Reality Technologies • Feb 12

this requires http2, right ? SSE requires server-push which are available after http2

zakaria chahboun • Feb 12

Actually, SSE doesn't require HTTP/2. It's designed to work over HTTP/1.1 as well. Unlike HTTP/2's server push, which allows the server to proactively push resources to the client, SSE uses a single open connection over HTTP to stream events to the client. The key here is that SSE works through a long-lived connection, but doesn't require the features of HTTP/2 like multiplexing or server push.

Troy High • Feb 12

@ffreality , SSE works with regular http, however, there is a connection limitation as @dylan_westraadt_92f0c807d mentioned. If using http/2 then the connection limit can be negotiated.

Mohit Majumdar • Feb 12

can we get same SSE for python based backends???

zakaria chahboun • Feb 12

Yes, Just an HTTP GET request with specific headers 😊

Dylan Westraadt • Feb 12

SSE has a limit of 6 connections per browser window. Just something to keep in mind. Its not a one size fits all solution.

peerreynders • Feb 12

It's 6 connections (i.e. requests, not just SSE) per domain across the entire browser for HTTP/1.x. The limit is a lot higher for HTTP/2.

That said architecturally the plan would be to multiplex all traffic over a single SSE for the entire page and for an MPA to use leader election where only one page of the domain would use an SSE and redistribute the events to the other pages from the same domain via BroadcastChannel.

zakaria chahboun • Feb 12

Yes, But you can use one connection with multiple events.

KUNDAN KUMAR • Feb 12

Hi
I tried SSE in my project. It worked great but I was not able to configure nginx properly for this.
If you have any suggestions please let me know.
Thanks in advance.

zakaria chahboun • Feb 12

SSE requires keeping the connection open for a longer time, so you need to make sure NGINX is configured to handle that.

Here are a few suggestions:

Increase the buffer size and timeouts: SSE streams data continuously, so you need to adjust some NGINX settings. For instance, you might need to set a larger buffer and increase the timeout:

location /events {
    proxy_pass http://your_backend_server;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'keep-alive';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # Adjust timeouts for long-running connections
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;

    # Optional: Disable buffering for real-time data
    proxy_buffering off;
    client_max_body_size 0;
}

Keep the connection alive: Make sure the server and NGINX don’t timeout prematurely while the connection is open. The proxy_read_timeout and proxy_send_timeout parameters are key here.
Turn off buffering: SSE requires that data be pushed to the client immediately, so turning off buffering in NGINX with proxy_buffering off is important for real-time delivery.

Whatch this video:
youtu.be/qoEq_Ro1wjU