Hacker News Reader

Comment by hombre_fatal | Hacker News Reader

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.

View on HN

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.

I fixed a few bugs in a WebSocket client and was blown away by the things they do to trick old proxies into not screwing it all up.

I would be interested in those tricks

A big one is 'masking' all client requests that a proxy can't effectively cache the response since the request always changes.

The RFC explains it: https://datatracker.ietf.org/doc/html/rfc6455#section-5.3

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?

Do you mean web workers? https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

On the other hand, we're doing the worse tactic of getting held up on the first tiny subheader instead of focusing on the rest of a decent article.

Also, their alternative is just a library. It's not like they're selling a SaaS, so we shouldn't be mean spirited.

> ...we shouldn't be mean spirited.

Am I on the right website? checks URL

People find anything to be mean about on here.

But it is frowned upon.

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.

The loaf shouldn't be in the fridge, and 2.1mm is way too much butter, especially if applied before putting the bread in the toaster

Sandwich code review is what HN is for.

sanwy.ch is the name of the YC25 startup tackling AI sandwich tech.

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.

Too much butter? You're not living if thats too much butter!

You butter bread before it’s toasted? My mind is honestly blown (as I move to kitchen to try this).

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.

Your comment is in step 1.

Yes, but we’re just talking about making websites here. Rolling your own HTTP is overkill, you’re not Google.

> Yes, but we’re just talking about making websites here.

And Twitter is just a message board.

Those who do not understand the problem domain complain that systems are too complex.

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.

That’s basically RPC over WS.

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

> games, anything with real time two-way interactivity

No need for WebSockets there as well. Check out WebTransport.

It even has mention as being the spiritual successor to WebSocket for certain cases in mdn docs:

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...

"if your application requires a non-standard custom solution, then you should use the WebTransport API"

That's a pretty convincing use-case. Why use something standard if it can be non-standard custom instead!

Your projects require holistic and craft solutions. Simple, working ways are the wrong path!

WebTransport is great but it's not in safari yet.

> No need for WebSockets there as well. Check out WebTransport.

Isn't WebTransport basically WebSockets reimplemented in HTTP/3? What point where you trying to make?

> Isn't WebTransport basically WebSockets reimplemented in HTTP/3?

No.

> 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

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.

He said "basically" which should be interpreted as "roughly"? Then it seems his assert is roughly correct?

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.

Last time I've checked none of the common reverse proxy servers (most importantly nginx) supported WebTransport.

> 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.

What in particular would you say?

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?

Ref: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...

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.

The WebSocket browser APIs don't support ping/pong

Native EventSource doesn’t let you set headers ([issue](https://github.com/whatwg/html/issues/2177)), so it’s harder to handle authentication.

> sending a RequestID to the server so that you get request/response cycles isn't weird nor beyond the pal

There's even a whole spec for that: JSON-RPC, and it's quite popular.

IMAP uses request IDs.

Reply on news.ycombinator.com