I think what you are getting at is that websockets aren't as simple as http traffic through a proxy, but you absolutely can use proxies and ws connections just fine and for a variety of reasons.
For all the other comments, parent is probably talking about forward proxies and to their point many forward/enterprise proxies have configurations which cause websockets to break and it is a pain to debug this if you have many enterprise customers.
Echoing this. At $DAYJOB some 5-10% of customers will fail to initiate a websocket connection, even over wss:// despite plain HTTPS requests working fine. This is a client-side issue with whatever outdated HTTP CONNECT implementation the enterprise has.
Cloudflare doesn't officially support SSE, but if you send keepalives events every 15 or 20sec or so you can reliably use SSE for 40 min + in my experiance.
No server traffic for 100+ sec officially results in a 524, so you could possibly make that keepalive interval longer, but I haven't tested it.
Make sure to have the new style cache rule with Bypass cache selected and absolutely make sure you are using HTTP/2 all the way to the origin.
The 6 connections per browser limit of HTTP/1.1 SSE was painful, and I am pretty sure auto negotiation breaks, often in unexpected ways with a HTTP/1.1 origin.
On top of the comments below about SSE, I'd also point out that Cloudflare is doing some interesting stuff around serverless resumable websockets. They also have stuff for WebRTC.
I've noticed some weird behaviors with the EventSource impl that browsers ship with. Chief among them being the default behavior is to infinitely reconnect after the server closes the stream, so you have to coordinate some kind of special stop event to stop the client from reconnecting. You wouldn't have that problem with the stream object from Response.body
The SSE protocol is actually just a long-running stream like I mentioned but with specific formatting for each chunk (id, event, and data fields)
as a side note, eventkit actually exports utilities to support SSE both on client and server. The reason you'd want to use eventkit in either case is because it ships with some extra transformation and observability goodies. https://hntrl.github.io/eventkit/guide/examples/http-streami...
The reconnect thing is actually quite helpful for mobile use cases. Say the user switches the tab, closes their browser or loses network and then they return. Since SSE is stateless from the client's perspective, the client can just reconnect and continue receiving messages. Whereas with WS there's handshakes to worry about--and also other annoyances like what to do with pending requests before connection was lose.
I don't know why people keep trying desperately to avoid the simplicity and flexibility of WebSockets.
A lot of times, what people need is a bidirectional connection yet somehow they convince themselves that SSE is better for the job... But they end up with two different types of streams; HTTP for writes and responses and SSE for passively consuming real-time data... Two different stream types with different lifecycles; one connection could fail while the other is fine... There is no way to correctly identify what is the current connection status of the app because there are multiple connections/statuses and data comes from multiple streams... Figuring out how to merge data coming from HTTP responses with data coming in passively from the SSE is messy and you have no control over the order in which the events are triggered across two different connections...
You can't enforce a serial, sequential, ordered flow of data over multiple connections as easily, it gets messy.
With WebSockets, you can easily assign an ID to requests and match it with a response. There are plenty of WebSocket frameworks which allow you to process messages in-order. The reason they work and are simple is because all messages pass over a single connection with a single state. Recovering from lost connections is much more straight forward.
who's to say your data is coming from multiple streams? You can propagate any updates you need to make in the application to a single stream (like SSE or a long-lived response) in place of a WebSocket. your http responses can just be always 204 if all they're doing is handling updates and pushing events to aforementioned single stream.
It should say "When used over HTTP/1" instead of "When not used over HTTP/2" because nowadays we also have HTTP/3, and browsers barely even use HTTP/1, so I would say it's pretty safe to ignore that warning.
> Unless you mean on HTTP2?
Any version of HTTP that supports multiplexing.
> But aren't WS connections also multiplexed over HTTP2 in that case?
There is RFC 8441 but I don't think it's actually implemented in the browsers.
SSE is great. Most things with websockets would be fine with SSE.
Also I don't see it being much easier here than a few primitives and learning about generator functions if you haven't had experience with them. I appreciate the helper, but the API is pretty reasonable as-is IMO
The helper example was a sore attempt to plug the project I've been working on (tinkering with it is how I came up with the example). The library I plugged has much more to do with enabling a more flexible reactive programming model in js, but just so happens to plug into the stream API pretty handily. Still an interesting look IMO if you're into that kind of stuff
No worries, I know how it feels! (I said, plugging away my own project in a sibling comment, lol)
I do like the reactive approach (in fact, I’ve reinvented something similar over SSE). I feel a standards-based solution is just ever so slightly more robust/universal.
I’m experimenting with SSE for realtime project deployment logs in https://lunni.dev/ and it’s been extremely pleasant so far.
The only problem is, if you want to customize the request (e.g. send a POST or add a header),you have to use a third-party implementation (e.g. one from Microsoft [1]), but I hope this can be fixed in the standards later.
SSE doesn't support binary data without encoding to something base64 first. These days I'd recommend a fetch stream with TLV messages first, followed by WebSocket.
One thing I couldn’t get working with websockets is how do you keep websocket connections active during code deployments without disconnecting current connected clients?
Sounds very tricky to me to get right even at scale.
The trick is to make the connection stateless, i.e. any client can connect to any server (just like plain HTTP). Then when there's a new deployment the websocket connection will be terminated and the client can reconnect instantly, automatically finding the next available server.
It's a minor point in the article, but sending a RequestID to the server so that you get request/response cycles isn't weird nor beyond the pale.
It's pretty much always worth it to have an API like `send(message).then(res => ...)` in a serious app.
But I agree. The upgrade request is confusing, and it's annoying how your websocket server is this embedded thing running inside your http server that never integrates cleanly.
Like instead of just reusing your middleware that reads headers['authorization'] from the websocket request, you access this weird `connectionParams` object that you pretend are request headers, heh.
But the idiosyncrasies aren't that big of a deal (ok, I've just gotten used to them). And the websocket browser API is nicer to work with than, say, EventSource.
It's a good well worn tactic. You list in very high detail every single step of any process you don't like. It makes that process seem overly complex, then you can present your alternative and it sounds way simpler.
For example, making a sandwich: You have to retrieve exactly two slices of bread after finding the loaf in the fridge. Apply butter uniformly after finding the appropriate knife, be sure to apply about a 2.1mm level of coating. After all of that you will still need to ensure you've calibrated the toaster!"
Pretty much. In this case, WebSockets is simpler to implement than HTTP2; it's closer to raw TCP, you just send and receive raw packets... It's objectively simpler, more efficient and more flexible.
It's a tough sell to convince me that a protocol which was designed primarily for resource transfer via a strict, stateless request-response mode of interaction, with server push tacked on top as an afterthought is simpler than something which was built from the ground up to be bidirectional.
Aren't websockets the only way to some sort of actual multi-core and threaded code in JavaScript, or is it still subject to the single background thread limitation and it just runs like node does?
Absolutely. The author conveniently leaves out the benefit that websockets enable ditching the frontend js code--included is the library the author is plugging. The backend shouldn't send back an error message to the frontend for rendering, but, instead, a rendered view.
I think we need a function that returns the correct butter height given the dimensions of the input bread. We may also need an object containing different kinds of bread and the ideal amount of butter for each depending on the absorbtion characteristics of the bread, etc. The user's preference for butter might also need to be another parameter.
> sending a RequestID to the server so that you get request/response cycles isn't weird nor beyond the pale.
To me the sticking point is what if the "response" message never comes? There's nothing in the websocket protocol that dictates that messages need to be acknowledged. With request/response the client knows how to handle that case natively
> And the websocket browser API is nicer to work with than, say, EventSource.
Yeah, you'd need a lib or roll your own that races the response against a timeout.
Kind of like how you also need to implement app-layer ping/pong over websockets for keepalive even though tcp already sends its own ping/pong. -_-
As for EventSource, I don't remember exactly, something always comes up. That said, you could say the same for websockets since even implementing non-buggy reconn/backaway logic is annoying.
I'll admit, time for me to try the thing you pitch in the article.
I have only small experience programming with web sockets, but I thought the ping pong mechanism is already built into the protocol. Does it have timeout? Does it help at the application layer?
You only need to implement it yourself if you’ve catastrophically fucked up the concurrency model on the client or sever side and they can’t respond out of band of whatever you’re waiting on.
Discord implements its own heartbeat mechanism. I've heard websocket-native ping is somehow unreliable. Maybe in case the websocket connection is fine but something happened at the application layer?
"Unreliable" is a bit harsh - the problem arises imho not from the websocket ping itself, but from the fact that client-side _and_ server-side need to support the ping/pong frames.
This article conflates a lot of different topics. If your WebSocket connection can be easily replaced with SSE+POST requests, then yeah you don’t need WebSockets. That doesn’t mean there aren’t a ton of very valid use cases (games, anything with real time two-way interactivity).
It seems you need to urgently reach out to the people working on WebTransport. You seem to know better and their documentation contradicts and refutes your assertion.
Where does that document say that WebTransport is just WebSockets over HTTP/3? The only thing in common is that both features provide reliable bi-directional streams, but WebTransport also supports unreliable streams and a bunch of other things. Please read the docs. There is also RFC 9220
Bootstrapping WebSockets with HTTP/3, which is literally WebSockets over HTTP/3.
Maybe? Isn't WebSockets basically TCP? Roughly? I wrote that WebSockets provide reliable bi-directional streams, but it actually doesn't. It implements message framing. WebTransport also doesn't support "unreliable streams", it's actually called "datagrams". WebTransport doesn't even have to be used over HTTP/3 per the latest spec, so is it basically WebSockets reimplemented in HTTP/3? No.
> (...) but WebTransport also supports unreliable streams and a bunch of other things.
If you take some time to learn about WebTransport, you will eventually notice that if you remove HTTP/3 from if you remove each and every single feature that WebTransport touts as changes/improvements over WebSockets.
This is how I used to do it over TCP, 20 years ago: each request message has a unique request ID which the server echoes and the client uses to match against a pending request. There is a periodic timer that checks if requests have been pending for longer than a timeout period and fails them with an error bubbled up to the application layer. We even had an incrementing sequence number in each message so that the message stream can resume after a reconnect. This was all done in C++e, and didn't require a large amount of code to implement. I was 25 years old at the time.
What the author and similar web developers consider complex, awkward or difficult gives me pause. The best case scenario is that we've democratized programming to a point where it is no longer limited to people with highly algorithmic/stateful brains. Which would be a good thing. The worst case scenario is that the software engineering discipline has lost something in terms of rigor.
Every web browser already has a built in system for matching requests and responses and checking if requests have been pending too long. There is no need to reinvent the wheel.
The real problem with the software engineering discipline is that we are too easily distracted from solving the actual business problem by pointless architecture astronautics. At best because of boredom associated with most business problems being uninteresting, at worst to maliciously increase billable hours.
> The real problem with the software engineering discipline is that we are too easily distracted from solving the actual business problem by pointless architecture astronautics.
There are two pervasive themes in software engineering:
- those who do not understand the problem domain complaining that systems are too complex.
- those who understand the problem domain arguing that the system needs to be refactored to shed crude unmaintainable hacks and further support requirements it doesn't support elegantly.
I am beginning to see this increasingly. Apps that make the most basic of mistakes. Some new framework trying to fix something that was already fixed by the previous 3 frameworks. UX designs making no sense or giving errors that used to be solved. From small outfits (that’s fair) to multi billion dollar companies (you should know better) , I feel that rigor is definitely lacking.
A framework was recently posted here where the author was comparing how great their Rust-to-WASM client side state management could handle tens of thousands of records which would cause the JS version of their code to stack overflow...
...and yes, the stack overflow in the JS version was trivially fixable and then the JS version worked pretty well.
There is a huge difference between guaranteeing algorithmic security of an endpoint, e.g. getting authentication correct, and anticipating every security issue that often has nothing to do with developer code. The former is possible, the latter is not. I understand the author here not wishing to deal with the websocket upgrade process - I would be surprised if there aren’t zero-days lurking there somewhere.
Reads like a series of strawman arguments if you replace "WebSockets" with socket.io.
- "messages aren’t transactional": You can process request and return a value to sender in socket.io application layer. Is that transactional enough?
- "If you’re sending messages that don’t necessarily need to be acknowledged (like a heartbeat or keyboard inputs), then Websockets make a great fit". But socket.io has acknowledgements.
- "When a new WebSocket connection is initiated, your server has to handle the HTTP “upgrade” request handshake.". You can bypass handshake and go straight to WS even in Websockets, and if you don't socket.io handles upgrade for you pretty nicely so you not parsing HTTP header ..
It's like arguing web components suck because there is all these problems you need to solve, while pretending web component frameworks (React, Vue, Angular, ..) that solve all those problems don't exist.
>> If it wasn’t, we couldn’t stream video without loading the entire file first
I don't believe this is correct. To my knowledge, video stream requests chunks by range and is largely client controlled. It isn't a single, long lived http connection.
I believe that's standard for Netflix, etc, but is it also true for plain webms and mp4s in a <video> tags? I thought those were downloaded in one request but had enough metadata at the beginning to allow playback to start before the file is completely downloaded.
Browsers talking to static web servers use HTTP byte ranges requests to get chunks of videos and can use the same mechanism to seek to any point in the file.
Streaming that way is fast and simple. No fancy technology required.
For MP4 to work that we you need to render it as fragmented MP4.
Seconded, ive done a userland 'content-range' implementation myself. of course there were a few ffmpeg specific parameters the mp4 needed to work right still
Why would the browser send byte range requests for video tags if it expects to play the file back linearly from beginning to end anyway? Wouldn't that be additional overhead/round-trips?
My original comment was about the commenter I replied to saying:
> To my knowledge, video stream requests chunks by range and is largely client controlled. It isn't a single, long lived http connection.
Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"? Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly?
Both are possible, and in fact I could imagine not all servers being too happy with having to trickle data over a persistent HTTP connection through the entire length of the video, with an almost always full TCP send buffer at the OS level.
It is possible if you are in control of the client, but no browser would stream an mp4 file request by request.
> with an almost always full TCP send buffer at the OS level
This shouldn't be a problem because there is flow control. Also the data would probably be sent to the kernel in small chunks, not the whole file at once.
> This shouldn't be a problem because there is flow control.
It's leveraging flow control, but as I mentioned this might be less efficient (in terms of server memory usage and concurrent open connections, depending on client buffer size and other variables) than downloading larger chunks and closing the HTTP connection in between them.
Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle.
> I believe most browsers do it like that, these days
Nope. Browsers send a byte range request for the whole file (`0-`), and the correspoding time range grows as the file is being downloaded. If the user decided to seek to a different part of the file, say at byte offset 10_000, the browser would send a second byte range request, this time `10000-` and a second time range would be created (if this part of the file has not already been downloaded). So there is no evidence there that any browser would stream files in small chunks, request by request.
> in terms of server memory usage
It's not less efficient in terms of memory usage because the server wouldn't read more data from the filesystem than it can send with respect to the flow control.
> concurrent open connections
Maybe if you're on HTTP/1, but we live in the age of HTTP/2-3.
> Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle.
AFAIK browsers don't throttle download speed, if that's what you mean.
Ah, interesting, I must have mixed it up/looked at range request based HLS playlists in the past. Thank you!
> AFAIK browsers don't throttle download speed, if that's what you mean.
Yeah, I suppose by implementing a relatively large client-application-side buffer and reading from that in larger chunks rather than as small as the media codec allows, the same outcome can be achieved.
Reading e.g. one MP3 frame at a time from the TCP buffer would effectively throttle the download, limited only by Nagle's Algorithm, but that's probably still much too small to be efficient for radios that prefer to sleep most of the time and then receive large bursts of data.
Realistically you wouldn’t be reading anything from the TCP buffer because you would have TLS between your app and TCP, and it’s pretty much guaranteed that whatever TLS you’re using already does buffering.
That's effectively just another small application layer buffer though, isn't it? It might shift what would otherwise be in the TCP receive buffer to the application layer on the receiving end, but that should be about all the impact.
Oh you’re right, I’m just so used to making the TLS argument because there is also the cost of syscalls if you make small reads without buffering, sorry xD
Common sense tells me there should be some kind of limit, but I don't know what it is, whether it's standardized and whether it exists. I just tested and Firefox _buffered_ (according to the time range) the first 27_000~ seconds, but in the dev tools the request appeared as though still loading. Chrome downloaded the first 10.2 MB (according to dev tools) and stopped (but meanwhile the time range was growing from zero approximately by one second every second, even though the browser already stopped downloading). After it played for a bit, Chrome downloaded 2.6 more MB _using the same request_. In both cases the browser requested the whole file, but not necessarily downloaded the whole file.
> Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"?
Yes, it would (though a better description would be "a single, long lived http request" because this doesn't have anything to do with connections), and wewewedxfgdf also replied Yes.
> Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly?
It’s not true because throwing a video file as a source on video tag has no information about the file being requested until the headers are pushed down. Hell back in 2005 Akamai didn’t even support byte range headers for partial content delivery, which made resuming videos impossible, I believe they pushed out the update across their network in 06 or 07.
If your HTTP server provides and supports the appropriate headers and you’re serving supported file types, then it absolutely is true.
Just putting a url in my Chromium based browser’s address bar to an mp4 file we have hosted on CloudFlare R2 “just works” (I expect a video tag would be the same), supporting skipping ahead in the video without having to download the whole thing.
Initially skipping ahead didn’t work until I disabled caching on CloudFlare CDN as that breaks the “accept-range” capability on videos. For now we have negligible amount of viewership of these mp4s, but if it becomes an issue we’ll use CloudFlare’s video serving product.
> If your HTTP server provides and supports the appropriate headers and you’re serving supported file types, then it absolutely is true.
No. When you play a file in the browser with a video tag. It requests the file. It doesn’t ask for a range. It does use the range if you seek it, or you write the JavaScript to fetch based on a range. That’s why if you press play and pause it buffers the whole video. Only if you write the code yourself can you partially buffer a while like YouTube does.
Nah, it uses complex video specific logic and http range requests as protocol. (At least the normal browsers and servers. You can roll your own dumb client/server of course.)
> That’s why if you press play and pause it buffers the whole video.
Obviously it doesn’t initially ask for a range if it starts from the beginning of the video, but it starts playing video immediately without requiring the whole file to download, when you seek it cancels the current request and then does a range request. At no point does it “have” to cache the entire file.
I suppose if you watch it from start to finish without seeking it might cache the entire file, but it may alternatively keep a limited amount cached of the video and if you go back to an earlier time it may need to re-request that part.
Your confidence seems very high on something which more than one person has corrected you on now, perhaps you need to reassess the current state of video serving, keeping in mind it does require HTTP servers to allow range requests.
Who cares what happened in 2005? This is so rare nowadays, I've only really seen it on websites that are constructing the file as they go, such as the Github zip download feature.
You can also watch it happen - the Chrome developer tools network tab will show you the traffic that goes to and from the web browser to the server and you can see this process in action.
2005 is basically the dark ages of the web. It’s pre Ajax and ie6 was the dominant browser. Using this as an argument is like saying apps aren’t suitable because the iPhone didn’t have an App Store until 2008.
> It’s not true because throwing a video file as a source on video tag has no information about the file being requested until the headers are pushed down.
And yet, if you stick a web server in front of a video and load it in chrome, you’ll see just that happening.
<video controls>
<source src="/video/sample.mp4" type="video/mp4">
Your browser does not support the video tag.
</video>
into a html file, and run it against this pastebin [0], you'll see that chrome (and safari) both do range requests out of the box if the fileis big enough.
The long answer is "it depends on how you do it" unsurprisingly video and voice/audio are probably the most different ways that you can "choose" to do distribution
They can playback as loading as long as they are encoded correctly fwiw (faststart encoded).
When you create a video from a device the header is actually at the end of the file. Understandable, it’s where the file pointer was and mp4 allows this so your recording device writes it at the end. You must re-encoded with faststart (puts the moov atom at the start) to make it load reasonably on a webpage though.
> Understandable, it’s where the file pointer was and mp4 allows this so your recording device writes it at the end.
Yet formats like WAVE which use a similar "chunked" encoding they just use a fixed length header and use a single seek() to get back to it when finalizing the file. Quicktime and WAVE were released around nearly the same time in the early 90s.
MP2 was so much better I cringe every time I have to deal with MP4 in some context.
At the expense of quite some overhead though, right?
MPEG-2 transport streams seem more optimized for a broadcast context, with their small frame structure and everything – as far as I know, framing overhead is at least 2%, and is arguably not needed when delivered over a reliable unicast pipe such as TCP.
Still, being able to essentially chop a single, progressively written MPEG TS file into various chunks via HTTP range requests or very simple file copy operations without having to do more than count bytes, and with self-synchronization if things go wrong, is undoubtedly nicer to work with than MP4 objects. I suppose that's why HLS started out with transport streams and only gained fMP4 support later on.
> and is arguably not needed when delivered over a reliable unicast pipe such as TCP.
So much content ended up being delivered this way, but there was a brief moment where we thought multicast UDP would be much more prevalent than it ended up being. In that context it's perfect.
> why HLS started out with transport streams and only gained fMP4 support later on.
Which I actually think was the motivation to add fMP4 to base MP4 in the first place. In any case I think MPEG also did a better job with DASH technically but borked it all up with patents. They were really stupid with that in the early 2010s.
Multicast UDP is widely used - but not on the Internet.
We often forget there are networks other than the Internet. Understandable, since the Internet is most open. The Internet is just an overlay network over ISPs' private networks.
SCTP is used in cellphone networks and the interface between them and legacy POTS networks. And multicast UDP is used to stream TV and/or radio throughout a network or building. If you have a "cable TV" box that plugs into your fiber internet connection, it's probably receiving multicast UDP. The TV/internet company has end-to-end control of this network, so they use QoS to make sure these packets never get dropped. There was a write-up posted on Hacker News once about someone at a hotel discovering a multicast UDP stream of the elevator music.
> If you have a "cable TV" box that plugs into your fiber internet connection, it's probably receiving multicast UDP.
That's a good point: I suppose it's a big advantage being able to serve the same, unmodified MPEG transport stream from a CDN, as IP multicast over DOCSIS/GPON, and as DVB-C (although I’m not sure that works like that, as DVB usually has multiple programs per transponder/transport stream).
It’s usually written to the end since it’s its not a fixed size and it’s a pain for recording and processing tools to rewrite the whole file on completion just to move the header to the start. You should always re-encode to move the header to the start for web though.
It’s something you see too much of online once you know about it but mp4 can absolutely have the header at the start.
For "VOD", that works (and is how very simple <video> tag based players sometimes still do it), but for live streaming, it wouldn't – hence the need for fragmented MP4, MPEG-DASH, HLS etc.
It does work for simpler codecs/containers though: Shoutcast/Icecast web radio streams are essentially just endless MP3 downloads, optionally with some non-MP3 metadata interspersed at known intervals.
The two are essentially the same thing, modulo trading off some unnecessary buffering on both sides of the TCP pipe in the "one big download" streaming model for more TCP connection establishments in the "range request to refill the buffer" one.
Yea this works for mp4 and HN seems confused about how.
The MOOV atom is how range requests are enabled, but the browser has to find it first. That's why it looks like it's going to download the whole file at first. It doesn't know the offset. Once it reads it, the request will be cancelled and targeted range requests will begin.
Correct.
HLS and Dash are industry standards. Essentially the client downloads a file which lists the files in various bitrates and chunks and the client determines which is best for the given connectivity.
And even if you are using a "regular" video format like mp4, browsers will still use range requests [1] to fetch chunks of the file in separate requests, assuming the server supports it (which most do).
Yes, the statement is patently wrong. There are a few very popular video formats whose main feature is chunking through HTTP, like HTTP Live Streaming or MPEG-DASH.
I wrote a subsystem the other day that used websockets for a server to distribute video conversion tasks.
After futzing with silly things like file transfers and communication protocols I chucked it out and rewrote it so the client does HTTP long polling of the server and uploads its renders via hTTP POST.
Not really the case for user-facing applications. Proxies can time out, detecting stalls is hard, reconnection is expensive, TCP slow start means higher latency, the overhead is huge for small messages. Implementing it properly is not trivial, the WebSocket standard was created precisely to improve on those shortcomings. Good for you that it works for your case, though if all you need is to listen to a stream you might also be better served by SSE.
I was asking since Socket.io, for example, takes care of file uploads, reconnection, the whole HTTP upgrade flow, and is extremely easy to use, both on client and server. On top of that it can fall back to long-polling if WS is not available.
Long polling is great for most things that don't need a realtime push. It just gets to be a strain on a server if you've got to set up and tear down lots of those connections from lots of users. Keeping a socket alive is a lot less resource intensive. Maybe it sounds stupid, but I've even converted PHP code that responded to long polling to handle the same polling over a socket to save resources. Most of my apps that need some kind of lazy updates actually work this way, and fall back to REST polling the same services if the socket is down.
Genuine question because I agree that there are a lot of over complicated systems. I often see people say all you need is SQLite. Do you implement replication yourself? Or you are just accepting that if something happens to your server your data is just gone? I always default to managed Postgres and that seems to be the simplest most boring solution.
SQLite is absolutely not suitable if you need non-trivial amounts of write concurrency - SQLite locks the file when writing, and doesn't even notify the next writer when done - writers poll to see if it's unlocked yet. If you don't use WAL mode, then readers have to wait for writers to.
You can still back up your SQLite database file. You shouldn't do it in the middle of a write, or you should use the SQLite backup API to manage concurrency for you, or you can back it up in SQL dump format. This isn't one of the usual reasons you shouldn't use SQLite. If you need synchronous replication, then you shouldn't use SQLite.
SQLite is robust against process crashes and even operating system crashes if fsync works as it should (big if, if your data is important), but not against disk failure.
In most of the cases when you shouldn't use SQLite, you should still just upgrade one step to Postgres, not some random NoSQL thing or Google-scale thing.
The problem with HTTP2 is that the server-push aspect was tacked on top of an existing protocol as an afterthought. Also, because HTTP is a resource transfer protocol, it adds a whole bunch of overheads like request and response headings which aren't always necessary but add to processing time. The primary purpose of HTTP2 was to allow servers to preemptively push files/resources to clients to avoid round-trip latency; to reduce the reliance on script bundles.
WebSockets is a simpler protocol built from the ground up for bidirectional communication. It provides a lot more control over the flow of data as everything passes over a single connection which has a single lifecycle. It makes it a lot easier to manage state and to recover cleanly from a lost connection when you only have one logical connection. It makes it easier to process messages in a specific order and to do serial processing of messages. Having just one connection also greatly simplifies things in terms of authentication and access control.
I considered the possibility of switching the transport to HTTP2 for https://socketcluster.io/ years ago, but it's a fundamentally more complex protocol which adds unnecessary overheads and introduces new security challenges so it wasn't worth it.
How can server push be a problem with HTTP/2 if nobody supports server push? It's dead. And what about multiplexing and header compression? Not worth it?
> The primary purpose of HTTP2 was to allow servers to preemptively push files/resources to clients to avoid round-trip latency; to reduce the reliance on script bundles.
The primary purpose for HTTP2 was to allow multiple simultaneous asynchoronous http calls, which is a massive loading performance boost for most websites. Server push was very much a tacked on afterthought.
> The primary purpose of HTTP2 was to allow servers to preemptively push files/resources to clients to avoid round-trip latency; to reduce the reliance on script bundles.
No, it was not. The primary goal of HTTP/2 was to get over traditional connection limits through connection multiplexing because browsers treat TCP connections as an extremely scarce resource. Multiplexing massively improves the ability to issue many asynchronous calls, which are very common -- and H2 went on to make the traditional HTTP stack more efficient across the board (i.e. header compression.) Some of the original HTTP/2 demo sites that popped up after Google first supported it in Chrome were of loading many images over HTTP/1 vs HTTP/2, which is very common. In one case of my own (fetching lots of small < 1kb files recursively from S3, outside the browser) HTTP/2 was like a 100x performance boost over HTTP/1 or something.
You're correct Server Push was tacked on and known to be flawed very early on, and it took a while before everyone pulled the plug on it, but people fixated on it because it just seemed really cool, from what I can tell. But it was never the lynchpin of the thing, just a (failed and experimental) boondoggle.
You can add a recurring ping/pong between the client/server so you can know with some recency that the connection has been lost. You shouldn't have to do that, but you probably want to until this bug is fixed.
We've got multiple internal apps using WebSockets in production, for years. I have to say I don't really get all the concern in the article about upgrading the connection - any decent backend framework should handle this for you without a problem.
Hacker News articles on new libraries generally live in the 1% of the 1%. For lots of websites, they don't need a web-socket because they are just doing CRUD. For the 1% doing live updates, web-sockets are great and straight-forward. For whatever specialised use case the article has, sure there's something even less well supported you can pivot to.
We use a much short heartbeat interval because our use case is for real time control and monitoring so our users need to know immediately if the connection is lost.
I think at this point in my career my goal is to continue to never, ever, work on a public-facing website. 20 years into this foray of a career and I’ve avoided it so far.
The article forgot to mention websockets add state to the server! Load balancing will require sticking sessions. At scale this tends to mean separating websocket servers completely from http servers.
People interested in HTTP streaming should check out Braid-HTTP: https://braid.org. It adds a standard set of semantics that elegantly extend HTTP with event streaming into a robust state synchronization protocol.
You can also use long polling, which keeps alive a connection so the server can respond immediately when there’s new data. For example:
Server
const LONG_POLL_SERVER_TIMEOUT = 8_000
function longPollHandler(req, response) {
// e.g. client can be out of sync if the browser tab was hidden while a new event was triggered
const clientIsOutOfSync = parseInt(req.headers.last_received_event, 10) !== myEvents.count
if (clientIsOutOfSync) {
sendJSON(response, myEvents.count)
return
}
function onMyEvent() {
myEvents.unsubscribe(onMyEvent)
sendJSON(response, myEvents.count)
}
response.setTimeout(LONG_POLL_SERVER_TIMEOUT, onMyEvent)
req.on('error', () => {
myEvents.unsubscribe(onMyEvent)
response.destroy()
})
myEvents.subscribe(onMyEvent)
}
Client (polls when tab is visible)
pollMyEvents()
document.addEventListener('visibilitychange', () => {
if (!document.hidden)
pollMyEvents()
})
pollMyEvents.isPolling = false
pollMyEvents.oldCount = 0
async function pollMyEvents() {
if (pollMyEvents.isPolling || document.hidden)
return
try {
pollMyEvents.isPolling = true
const response = await fetch('/api/my-events', {
signal: AbortSignal.timeout(LONG_POLL_SERVER_TIMEOUT + 1000),
headers: { last_received_event: pollMyEvents.oldCount }
})
if (response.ok) {
const nMyEvents = await response.json()
if (pollMyEvents.oldCount !== nMyEvents) { // because it could be < or >
pollMyEvents.oldCount = nMyEvents
setUIState('eventsCount', nMyEvents)
}
pollMyEvents.isPolling = false
pollMyEvents()
}
else
throw response.status
}
catch (_) {
pollMyEvents.isPolling = false
setTimeout(pollMyEvents, 5000)
}
}
What does this solve? Genuine question. You still have to manage connectivity, and synchronization. Also not so sure that stream reading will necessarily be quantized chunks of your updates sent from the server.
We have multiple mission-critical, industrial-grade WebSocket monitoring applications that have been running rock-solid for the last eight years without any hiccups in manufacturing environments. It seems like you're taking an easy-to-maintain codebase and turning it into a complex monstrosity.
> We can’t reliably say “the next message” received on the stream is the result of the previous command since the server could have sent any number of messages in between now and then.
Doing so is a protocol decision though, isn't it?
If the protocol specifies that the server either clearly identifies responses as such, or only ever sends responses, and further doesn't send responses out of order, I don't see any difference to pipelined HTTP: The client just has to count, nothing more. (Then again, if that's the use case, long-lived HTTP connections would do the trick just as well.)
276 comments
[ 2.9 ms ] story [ 281 ms ] threadWhy not just use SSE? https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
That said, I like SSE for unidirectional string-encoded events.
(it's not SSE in particular, but it demonstrates that you can have a long running stream like SSE)
No server traffic for 100+ sec officially results in a 524, so you could possibly make that keepalive interval longer, but I haven't tested it.
Make sure to have the new style cache rule with Bypass cache selected and absolutely make sure you are using HTTP/2 all the way to the origin.
The 6 connections per browser limit of HTTP/1.1 SSE was painful, and I am pretty sure auto negotiation breaks, often in unexpected ways with a HTTP/1.1 origin.
The SSE protocol is actually just a long-running stream like I mentioned but with specific formatting for each chunk (id, event, and data fields)
as a side note, eventkit actually exports utilities to support SSE both on client and server. The reason you'd want to use eventkit in either case is because it ships with some extra transformation and observability goodies. https://hntrl.github.io/eventkit/guide/examples/http-streami...
A lot of times, what people need is a bidirectional connection yet somehow they convince themselves that SSE is better for the job... But they end up with two different types of streams; HTTP for writes and responses and SSE for passively consuming real-time data... Two different stream types with different lifecycles; one connection could fail while the other is fine... There is no way to correctly identify what is the current connection status of the app because there are multiple connections/statuses and data comes from multiple streams... Figuring out how to merge data coming from HTTP responses with data coming in passively from the SSE is messy and you have no control over the order in which the events are triggered across two different connections...
You can't enforce a serial, sequential, ordered flow of data over multiple connections as easily, it gets messy.
With WebSockets, you can easily assign an ID to requests and match it with a response. There are plenty of WebSocket frameworks which allow you to process messages in-order. The reason they work and are simple is because all messages pass over a single connection with a single state. Recovering from lost connections is much more straight forward.
https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...
Unless you mean on HTTP2? But aren't WS connections also multiplexed over HTTP2 in that case?
It should say "When used over HTTP/1" instead of "When not used over HTTP/2" because nowadays we also have HTTP/3, and browsers barely even use HTTP/1, so I would say it's pretty safe to ignore that warning.
> Unless you mean on HTTP2?
Any version of HTTP that supports multiplexing.
> But aren't WS connections also multiplexed over HTTP2 in that case?
There is RFC 8441 but I don't think it's actually implemented in the browsers.
Found this: https://github.com/mattermost/mattermost/issues/30285
It looks like it's supported in Chrome and Firefox but not in Safari.
These are tools, not religions.
Websockets have some real downsides if you don't need bidirectional comms.
Also I don't see it being much easier here than a few primitives and learning about generator functions if you haven't had experience with them. I appreciate the helper, but the API is pretty reasonable as-is IMO
I do like the reactive approach (in fact, I’ve reinvented something similar over SSE). I feel a standards-based solution is just ever so slightly more robust/universal.
The only problem is, if you want to customize the request (e.g. send a POST or add a header),you have to use a third-party implementation (e.g. one from Microsoft [1]), but I hope this can be fixed in the standards later.
[1]: https://www.npmjs.com/package/@microsoft/fetch-event-source
Sounds very tricky to me to get right even at scale.
It's pretty much always worth it to have an API like `send(message).then(res => ...)` in a serious app.
But I agree. The upgrade request is confusing, and it's annoying how your websocket server is this embedded thing running inside your http server that never integrates cleanly.
Like instead of just reusing your middleware that reads headers['authorization'] from the websocket request, you access this weird `connectionParams` object that you pretend are request headers, heh.
But the idiosyncrasies aren't that big of a deal (ok, I've just gotten used to them). And the websocket browser API is nicer to work with than, say, EventSource.
For example, making a sandwich: You have to retrieve exactly two slices of bread after finding the loaf in the fridge. Apply butter uniformly after finding the appropriate knife, be sure to apply about a 2.1mm level of coating. After all of that you will still need to ensure you've calibrated the toaster!"
It's a tough sell to convince me that a protocol which was designed primarily for resource transfer via a strict, stateless request-response mode of interaction, with server push tacked on top as an afterthought is simpler than something which was built from the ground up to be bidirectional.
The RFC explains it: https://datatracker.ietf.org/doc/html/rfc6455#section-5.3
Also, their alternative is just a library. It's not like they're selling a SaaS, so we shouldn't be mean spirited.
Am I on the right website? checks URL
People find anything to be mean about on here.
To me the sticking point is what if the "response" message never comes? There's nothing in the websocket protocol that dictates that messages need to be acknowledged. With request/response the client knows how to handle that case natively
> And the websocket browser API is nicer to work with than, say, EventSource.
What in particular would you say?
Kind of like how you also need to implement app-layer ping/pong over websockets for keepalive even though tcp already sends its own ping/pong. -_-
As for EventSource, I don't remember exactly, something always comes up. That said, you could say the same for websockets since even implementing non-buggy reconn/backaway logic is annoying.
I'll admit, time for me to try the thing you pitch in the article.
Ref: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
This article conflates a lot of different topics. If your WebSocket connection can be easily replaced with SSE+POST requests, then yeah you don’t need WebSockets. That doesn’t mean there aren’t a ton of very valid use cases (games, anything with real time two-way interactivity).
No need for WebSockets there as well. Check out WebTransport.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
That's a pretty convincing use-case. Why use something standard if it can be non-standard custom instead!
Isn't WebTransport basically WebSockets reimplemented in HTTP/3? What point where you trying to make?
No.
Thanks for your insight.
It seems you need to urgently reach out to the people working on WebTransport. You seem to know better and their documentation contradicts and refutes your assertion.
https://github.com/w3c/webtransport/blob/main/explainer.md
If you take some time to learn about WebTransport, you will eventually notice that if you remove HTTP/3 from if you remove each and every single feature that WebTransport touts as changes/improvements over WebSockets.
What the author and similar web developers consider complex, awkward or difficult gives me pause. The best case scenario is that we've democratized programming to a point where it is no longer limited to people with highly algorithmic/stateful brains. Which would be a good thing. The worst case scenario is that the software engineering discipline has lost something in terms of rigor.
The real problem with the software engineering discipline is that we are too easily distracted from solving the actual business problem by pointless architecture astronautics. At best because of boredom associated with most business problems being uninteresting, at worst to maliciously increase billable hours.
There are two pervasive themes in software engineering:
- those who do not understand the problem domain complaining that systems are too complex.
- those who understand the problem domain arguing that the system needs to be refactored to shed crude unmaintainable hacks and further support requirements it doesn't support elegantly.
Your comment is in step 1.
And Twitter is just a message board.
Those who do not understand the problem domain complain that systems are too complex.
...and yes, the stack overflow in the JS version was trivially fixable and then the JS version worked pretty well.
There's even a whole spec for that: JSON-RPC, and it's quite popular.
Websockets are a web standard, socket.io is a userland framework
I don't believe this is correct. To my knowledge, video stream requests chunks by range and is largely client controlled. It isn't a single, long lived http connection.
Browsers talking to static web servers use HTTP byte ranges requests to get chunks of videos and can use the same mechanism to seek to any point in the file.
Streaming that way is fast and simple. No fancy technology required.
For MP4 to work that we you need to render it as fragmented MP4.
Probably because byte range is required for seeking, and playing from the beginning is equivalent to seeking at 0.
> Wouldn't that be additional overhead/round-trips?
No because the range of the initial byte range request is the whole file (`bytes=0-`).
> To my knowledge, video stream requests chunks by range and is largely client controlled. It isn't a single, long lived http connection.
Wouldn't a byte range request for the whole file fall under the "single, long lived http connection"? Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly?
It is possible if you are in control of the client, but no browser would stream an mp4 file request by request.
> with an almost always full TCP send buffer at the OS level
This shouldn't be a problem because there is flow control. Also the data would probably be sent to the kernel in small chunks, not the whole file at once.
I believe most browsers do it like that, these days: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Au...
> This shouldn't be a problem because there is flow control.
It's leveraging flow control, but as I mentioned this might be less efficient (in terms of server memory usage and concurrent open connections, depending on client buffer size and other variables) than downloading larger chunks and closing the HTTP connection in between them.
Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle.
Nope. Browsers send a byte range request for the whole file (`0-`), and the correspoding time range grows as the file is being downloaded. If the user decided to seek to a different part of the file, say at byte offset 10_000, the browser would send a second byte range request, this time `10000-` and a second time range would be created (if this part of the file has not already been downloaded). So there is no evidence there that any browser would stream files in small chunks, request by request.
> in terms of server memory usage
It's not less efficient in terms of memory usage because the server wouldn't read more data from the filesystem than it can send with respect to the flow control.
> concurrent open connections
Maybe if you're on HTTP/1, but we live in the age of HTTP/2-3.
> Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle.
AFAIK browsers don't throttle download speed, if that's what you mean.
> AFAIK browsers don't throttle download speed, if that's what you mean.
Yeah, I suppose by implementing a relatively large client-application-side buffer and reading from that in larger chunks rather than as small as the media codec allows, the same outcome can be achieved.
Reading e.g. one MP3 frame at a time from the TCP buffer would effectively throttle the download, limited only by Nagle's Algorithm, but that's probably still much too small to be efficient for radios that prefer to sleep most of the time and then receive large bursts of data.
Yes, it would (though a better description would be "a single, long lived http request" because this doesn't have anything to do with connections), and wewewedxfgdf also replied Yes.
> Sure it could be terminated early and another request made for seeking, but regardless the video can start before the whole file is downloaded, assuming it's encoded correctly?
Yes.
Just putting a url in my Chromium based browser’s address bar to an mp4 file we have hosted on CloudFlare R2 “just works” (I expect a video tag would be the same), supporting skipping ahead in the video without having to download the whole thing.
Initially skipping ahead didn’t work until I disabled caching on CloudFlare CDN as that breaks the “accept-range” capability on videos. For now we have negligible amount of viewership of these mp4s, but if it becomes an issue we’ll use CloudFlare’s video serving product.
No. When you play a file in the browser with a video tag. It requests the file. It doesn’t ask for a range. It does use the range if you seek it, or you write the JavaScript to fetch based on a range. That’s why if you press play and pause it buffers the whole video. Only if you write the code yourself can you partially buffer a while like YouTube does.
> That’s why if you press play and pause it buffers the whole video.
Browsers don't do that.
I suppose if you watch it from start to finish without seeking it might cache the entire file, but it may alternatively keep a limited amount cached of the video and if you go back to an earlier time it may need to re-request that part.
Your confidence seems very high on something which more than one person has corrected you on now, perhaps you need to reassess the current state of video serving, keeping in mind it does require HTTP servers to allow range requests.
https://www.zeng.dev/post/2023-http-range-and-play-mp4-in-br...
You can also watch it happen - the Chrome developer tools network tab will show you the traffic that goes to and from the web browser to the server and you can see this process in action.
> It’s not true because throwing a video file as a source on video tag has no information about the file being requested until the headers are pushed down.
And yet, if you stick a web server in front of a video and load it in chrome, you’ll see just that happening.
[0] https://pastebin.com/MyUfiwYE
When you create a video from a device the header is actually at the end of the file. Understandable, it’s where the file pointer was and mp4 allows this so your recording device writes it at the end. You must re-encoded with faststart (puts the moov atom at the start) to make it load reasonably on a webpage though.
Yet formats like WAVE which use a similar "chunked" encoding they just use a fixed length header and use a single seek() to get back to it when finalizing the file. Quicktime and WAVE were released around nearly the same time in the early 90s.
MP2 was so much better I cringe every time I have to deal with MP4 in some context.
MPEG-2 transport streams seem more optimized for a broadcast context, with their small frame structure and everything – as far as I know, framing overhead is at least 2%, and is arguably not needed when delivered over a reliable unicast pipe such as TCP.
Still, being able to essentially chop a single, progressively written MPEG TS file into various chunks via HTTP range requests or very simple file copy operations without having to do more than count bytes, and with self-synchronization if things go wrong, is undoubtedly nicer to work with than MP4 objects. I suppose that's why HLS started out with transport streams and only gained fMP4 support later on.
So much content ended up being delivered this way, but there was a brief moment where we thought multicast UDP would be much more prevalent than it ended up being. In that context it's perfect.
> why HLS started out with transport streams and only gained fMP4 support later on.
Which I actually think was the motivation to add fMP4 to base MP4 in the first place. In any case I think MPEG also did a better job with DASH technically but borked it all up with patents. They were really stupid with that in the early 2010s.
We often forget there are networks other than the Internet. Understandable, since the Internet is most open. The Internet is just an overlay network over ISPs' private networks.
SCTP is used in cellphone networks and the interface between them and legacy POTS networks. And multicast UDP is used to stream TV and/or radio throughout a network or building. If you have a "cable TV" box that plugs into your fiber internet connection, it's probably receiving multicast UDP. The TV/internet company has end-to-end control of this network, so they use QoS to make sure these packets never get dropped. There was a write-up posted on Hacker News once about someone at a hotel discovering a multicast UDP stream of the elevator music.
That's a good point: I suppose it's a big advantage being able to serve the same, unmodified MPEG transport stream from a CDN, as IP multicast over DOCSIS/GPON, and as DVB-C (although I’m not sure that works like that, as DVB usually has multiple programs per transponder/transport stream).
It’s usually written to the end since it’s its not a fixed size and it’s a pain for recording and processing tools to rewrite the whole file on completion just to move the header to the start. You should always re-encode to move the header to the start for web though.
It’s something you see too much of online once you know about it but mp4 can absolutely have the header at the start.
It does work for simpler codecs/containers though: Shoutcast/Icecast web radio streams are essentially just endless MP3 downloads, optionally with some non-MP3 metadata interspersed at known intervals.
The MOOV atom is how range requests are enabled, but the browser has to find it first. That's why it looks like it's going to download the whole file at first. It doesn't know the offset. Once it reads it, the request will be cancelled and targeted range requests will begin.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran...
Yes, the statement is patently wrong. There are a few very popular video formats whose main feature is chunking through HTTP, like HTTP Live Streaming or MPEG-DASH.
After futzing with silly things like file transfers and communication protocols I chucked it out and rewrote it so the client does HTTP long polling of the server and uploads its renders via hTTP POST.
So much easier.
Did you try using an established library like socket.io, connectRPC etc? They handle a lot of the complexity.
I was asking since Socket.io, for example, takes care of file uploads, reconnection, the whole HTTP upgrade flow, and is extremely easy to use, both on client and server. On top of that it can fall back to long-polling if WS is not available.
Here's a link for educational purposes: https://en.wikipedia.org/wiki/Comet_(programming)
Too many technology fads make things needlessly complicated, and complexity makes systems unreliable.
You might not need Kubernetes
You might not need The Cloud
You might not need more than SQLite
...and so on.
https://litestream.io https://github.com/benbjohnson/litestream
You can still back up your SQLite database file. You shouldn't do it in the middle of a write, or you should use the SQLite backup API to manage concurrency for you, or you can back it up in SQL dump format. This isn't one of the usual reasons you shouldn't use SQLite. If you need synchronous replication, then you shouldn't use SQLite.
SQLite is robust against process crashes and even operating system crashes if fsync works as it should (big if, if your data is important), but not against disk failure.
In most of the cases when you shouldn't use SQLite, you should still just upgrade one step to Postgres, not some random NoSQL thing or Google-scale thing.
WebSockets is a simpler protocol built from the ground up for bidirectional communication. It provides a lot more control over the flow of data as everything passes over a single connection which has a single lifecycle. It makes it a lot easier to manage state and to recover cleanly from a lost connection when you only have one logical connection. It makes it easier to process messages in a specific order and to do serial processing of messages. Having just one connection also greatly simplifies things in terms of authentication and access control.
I considered the possibility of switching the transport to HTTP2 for https://socketcluster.io/ years ago, but it's a fundamentally more complex protocol which adds unnecessary overheads and introduces new security challenges so it wasn't worth it.
The primary purpose for HTTP2 was to allow multiple simultaneous asynchoronous http calls, which is a massive loading performance boost for most websites. Server push was very much a tacked on afterthought.
No, it was not. The primary goal of HTTP/2 was to get over traditional connection limits through connection multiplexing because browsers treat TCP connections as an extremely scarce resource. Multiplexing massively improves the ability to issue many asynchronous calls, which are very common -- and H2 went on to make the traditional HTTP stack more efficient across the board (i.e. header compression.) Some of the original HTTP/2 demo sites that popped up after Google first supported it in Chrome were of loading many images over HTTP/1 vs HTTP/2, which is very common. In one case of my own (fetching lots of small < 1kb files recursively from S3, outside the browser) HTTP/2 was like a 100x performance boost over HTTP/1 or something.
You're correct Server Push was tacked on and known to be flawed very early on, and it took a while before everyone pulled the plug on it, but people fixated on it because it just seemed really cool, from what I can tell. But it was never the lynchpin of the thing, just a (failed and experimental) boondoggle.
And, that is why we have frameworks to at least in the case of Web Sockets, make things as easy as regular old REST.
https://issuetracker.google.com/issues/362210027?pli=1
You can add a recurring ping/pong between the client/server so you can know with some recency that the connection has been lost. You shouldn't have to do that, but you probably want to until this bug is fixed.
We've got multiple internal apps using WebSockets in production, for years. I have to say I don't really get all the concern in the article about upgrading the connection - any decent backend framework should handle this for you without a problem.
Hacker News articles on new libraries generally live in the 1% of the 1%. For lots of websites, they don't need a web-socket because they are just doing CRUD. For the 1% doing live updates, web-sockets are great and straight-forward. For whatever specialised use case the article has, sure there's something even less well supported you can pivot to.
Server
Client (polls when tab is visible) Working example at Mockaton: https://github.com/ericfortis/mockaton/blob/6b7f8eb5fe9d3baf...Doing so is a protocol decision though, isn't it?
If the protocol specifies that the server either clearly identifies responses as such, or only ever sends responses, and further doesn't send responses out of order, I don't see any difference to pipelined HTTP: The client just has to count, nothing more. (Then again, if that's the use case, long-lived HTTP connections would do the trick just as well.)