6 ms·
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 m
by hombre_fatal 2y ago
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.
- syspec 2y agoIt'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!"
- deleted 2y ago[deleted]
- jongjong 2y agoPretty 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.
- bobmcnamara 2y agoI 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.
- fenesiistvan 2y agoI would be interested in those tricks
- bobmcnamara 2y agoA 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 https://datatracker.ietf.org/doc/html/rfc6455#section-5.3
- AtlasBarfed 2y agoAren'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?
- nothrabannosir 2y agoDo you mean web workers? https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
- deleted 2y ago[deleted]
- hombre_fatal 2y agoOn 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.
- NetOpWibby 2y ago> ...we shouldn't be mean spirited. Am I on the right website? checks URL People find anything to be mean about on here.
- dizhn 2y agoBut it is frowned upon.
- waynesonfire 2y agoAbsolutely. 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.
- procaryote 2y agoThe 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
- goosejuice 2y agoToo much butter? You're not living if thats too much butter!
- iandanforth 2y agoSandwich code review is what HN is for.
- dcow 2y agosanwy.ch is the name of the YC25 startup tackling AI sandwich tech.
- accrual 2y agoI 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.
- plasma_beam 2y agoYou butter bread before it’s toasted? My mind is honestly blown (as I move to kitchen to try this).
- hntrl 2y ago> 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?
- hombre_fatal 2y agoYeah, 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.
- throwaway2037 2y agoI 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_API/Writing_WebSocket_servers#pings_and_pongs_the_heartbeat_of_websockets https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
- copperroof 2y agoYou 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.
- koakuma-chan 2y agoDiscord 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?
- ricardobeat 2y agoThat’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).
- koakuma-chan 2y ago> games, anything with real time two-way interactivity No need for WebSockets there as well. Check out WebTransport.
- hntrl 2y agoIt 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_API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_...
- almostnormal 2y ago"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!
- misiek08 2y agoYour projects require holistic and craft solutions. Simple, working ways are the wrong path!
- apitman 2y agoWebTransport is great but it's not in safari yet.
- motorest 2y ago> 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?
- hliyan 2y agoThis 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.
- Tabular-Iceberg 2y agoEvery 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.
- motorest 2y ago> 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.
- Tabular-Iceberg 2y ago
- cryptonector 2y agoIMAP uses request IDs.
- crabmusket 2y ago> 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.