Everyone defaults to WebSockets for real-time features. Most shouldn't.
The reality: 95% of "real-time" applications only need server → client upd...
For further actions, you may consider blocking this person and/or reporting abuse
One thing I think you are wrong is AI chat. That is best done with a websocket because then the conversation can keep the AI session, so that it has more context when sending a follow-up question.
Update: after a bit of of thinking about why OpenAI is using SSE and keeps the context is because they are sending the history with the newest question. That is going to burn tokens. As the company that is in charge of the tokens the application it can use, it is less of a problem.
But for us we don't want to burn through a lot of tokens.
It depends by the architecture, i think that the best option is to keep the context inside the "backend" and not sending it every time that i send a message (also if i'm not wronk, this should be the method used by claude)
I agree it depends. There are pros and cons for both methods.
My first thought was spending less money, that is why I stated it was wrong. But it is more nuanced.
Dear, Polliog!😉
Really enjoyed your deep dive on SSE vs WebSockets! 👏 I completely agree that for most real-time applications, unidirectional streaming is all you need, and SSE makes it so much simpler and easier to scale. Personally, I’ve been exploring SSE for dashboards and notifications, and the simplicity of built-in reconnects and HTTP/2 multiplexing has been a game-changer. I’d love to hear your thoughts on any edge cases where SSE might fall short or how you handle authentication and proxies in production. Definitely bookmarking this as a go-to reference for anyone thinking of simplifying their real-time architecture!
thank you^^
Thanks for sharing! The production use-case examples were super valuable 👍 Also agree that dashboards, notifications and chats rarely need full two-way data flow, at least haven’t encountered a requirement yet that couldn’t be covered by simple POST requests.
I mean, it depends by the architecture, but yes you can rely on POST + SSE, but if you need to that you can always use websocket with the two way connection
I agree with you. I like SSE, and I prefer using them to avoid some of the issues that can come with WebSockets.
I use them in my real-time dashboard app, Squidly, and managing those events is much easier than it would be with WebSockets
yeah I can relate, also nice app
Yeah this is one of those “everyone reaches for the bazooka” situations.
SSE being the default makes way more sense for most apps because most “real-time” is really just server broadcasting state while the client is basically a TV screen with buttons. Notifications, dashboards, logs, token streaming… that’s not a two-way conversation, it’s a one-way feed + occasional HTTP actions.
What I like about your breakdown is you’re not saying “WebSockets bad,” you’re saying WebSockets are expensive when you’re not using the expensive parts. The reconnection/heartbeats/sticky sessions/backplane stuff is the hidden tax nobody mentions in the “just add sockets” advice.
Also: the “3ms latency win” argument for WS is peak developer cope 😭. If your app has a 100ms+ end-to-end budget (most do), that 3ms is basically a rounding error compared to DB time, rendering, network variance, and whatever chaos is happening in prod.
I’d only add one practical footnote: SSE is boringly perfect until you hit “I need client → server real-time too,” and at that point the clean move is exactly what you hinted: SSE for downstream, HTTP POST for upstream. That combo covers an absurd amount of “real-time” products without turning your infra into a mini multiplayer game server.
So yeah — default SSE, earn WebSockets. That’s the energy.
There might be technical complexities if you want to do this from an environment like AWS Lambda - link:
medium.com/@johannesfloriangeiger/...
although it MIGHT be doable (not completely clear):
aws.amazon.com/about-aws/whats-new...
but those are details - in general I would think you have good points here!
Mhhh i'm going to review them, maybe i can do a follow up to this article
Honestly agree that SSE is underrated.
Many teams default to WebSockets without needing bi-directional complexity.
Have you seen any scaling pain points with SSE at higher concurrency?
No, not at all
I'm just dipping my toe into this topic and really appreciate all the detail and metrics you gave. Makes it easier to understand your reasoning. Thank you!