Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The WebSocket Handbook

ably.com

Post reply on HN
Print view View original

81–90 of 124 posts

Re: The WebSocket Handbook

#81

Post by mathgladiator »

superasn wrote: post #39
AlexTDiaconu wrote: post #2

Hi HN! I'm Alex, and I've been researching and writing about WebSockets for a while now. I'm the author of the recently released WebSocket Handbook. AMA about the WebSocket tech, the realtime web, Ably or anything related to Liverpool FC.

Hi! I want to create a web app like Google docs where multiple users can collaborate in real time to edit the document together (using a special link like gdocs generate). I want to save the docs in a MySQL db (no firebase) My questions are: 1) Since multiple people are working together how does one manage conflicts, i.e. 2 people sending different edits simultaneously. 2) If one clients gets disconnected (4g) and th…

CRDT solve a part of your problem, and an important consideration is whether or not you want off-line editing. If you don't need off-line editing, then a WebSocket can do it.

I'm actually using my project to build a collaborative IDE (designer like Figma): http://www.adama-lang.org/

I'm going to be launching it as a SaaS soon so people can spin up a new back-end without managing an infrastructure.

Re: The WebSocket Handbook

#82

Post by matsemann »

smaddock wrote: post #9

It's probably worth mentioning that WebTransport just shipped in Chrome 97 (2022-01-04), which seems to be a worthy successor to WebSockets [0]. It allows for reliable and unreliable modes which is a problem for games using WebSockets, among other things. [0] https://web.dev/webtransport/

Is this a new standard, or yet another thing Google is pushing and everyone else have to implement?

Re: The WebSocket Handbook

#83

Post by mathgladiator »

AlexTDiaconu wrote: post #2

Hi HN! I'm Alex, and I've been researching and writing about WebSockets for a while now. I'm the author of the recently released WebSocket Handbook. AMA about the WebSocket tech, the realtime web, Ably or anything related to Liverpool FC.

It's a good introduction, and it's a good document to introduce the problems induced by WebSockets (which Ably can come in an solve at scale).

I recently wrote about the Woes of Websocket: http://www.adama-lang.org/blog/woe-of-websocket with an errata based on HN feedback: http://www.adama-lang.org/blog/more-websocket-woe

The depth of this topic is very interesting, and I'm excited as I'm building some of the final pieces for my SaaS (which could compete with Ably).

Re: The WebSocket Handbook

#84

Post by mathgladiator »

paxys wrote: post #23

Before going all-in on websockets I'd like to caution people to thoroughly consider the server-side scaling challenges that come with it. HTTP servers have already solved traffic management, load balancing, scaling up and down, zero downtime deployments, A/B tests and experimentation and lots more to such a degree that we don't have to even think about them anymore. All of these problems come to the forefront again w…

I'm going all-in on WebSockets, but I've also seen how to solve all those problems at massive scale. You're right that these challenges are hard, and I don't believe we have an ideal shared offering yet.

We have a cultural challenge of how to manifest the opportunity and benefits presented by context rich communication over the entrenched ideology of statelessness and HTTP.

Re: The WebSocket Handbook

#85

Post by twic »

I use websockets quite a lot, for real-time dashboard kind of purposes.

The one thing i really wish websockets had is some kind of application-level acknowledgement or backpressure.

At the server end, you're blasting out messages to the client, but you have no idea if it is keeping up with them. Most of the time, it will be, but if there is a sudden spike of activity, suddenly all your dashboards are going wild, and the client may start to struggle. At that point, you want to be able to shed some load - delay messages a bit, then drop any message which gets superseded (eg if "reactor core temperature is 1050K" is buffered and you get "reactor core temperature is 1100K", you can drop the former). To do that, you need feedback about how far the client has got with processing messages.

You can build a feedback mechanism like this into your application protocol on top of websockets easily enough. But you probably want to do that from the start, or else you will, like me, one day look around and realise that retrofitting it to all your dashboards is a monumental effort.

The RSocket protocol might be a good start - it provides reactive streams semantics, and has a binding to websockets:

https://rsocket.io/guides/rsocket-js

Re: The WebSocket Handbook

#86

Post by mathgladiator »

PaulDavisThe1st wrote: post #31

Can anyone explain why using websockets with anything other than a webstack is so much hard than using regular ol' POSIX sockets, given that at some level websockets live right alongside a UDP or TCP socket? When we looked around for a library to use in Ardour to add websocket support, the choices were slim and none of them provided an API as simple as the one for UDP/TCP sockets.

It's related to what you can buy versus build. When you use a WebSocket, there may not be a great solution that fits your need. If you use just HTTP, then there is a wealth of options available to you.

Fundamentally, there is nothing special about a WebSocket over a socket rather than a special handshake, some framing, and the layering within an existing HTTP server. The problem is that the market of developers is vastly different. If you are a systems person, then chances are good you know sockets decently. If you are a typical web-dev, then the chances are not so great and its easy to make a mess that is then exposed to the world.

I've mentored teams, and the key challenge isn't technical but education on all the gotchas.

Re: The WebSocket Handbook

#87

Post by stichers »

lelanthran wrote: post #72
AlexTDiaconu wrote: post #2

Hi HN! I'm Alex, and I've been researching and writing about WebSockets for a while now. I'm the author of the recently released WebSocket Handbook. AMA about the WebSocket tech, the realtime web, Ably or anything related to Liverpool FC.

> or anything related to Liverpool FC. Do people still watch football? What are the viewership numbers for Liverpool FC? Does Man United still matter? :-)

Man Utd never mattered. Source: City supporter.

Re: The WebSocket Handbook

#88

Post by vulcan01 »

matsemann wrote: post #82
smaddock wrote: post #9

It's probably worth mentioning that WebTransport just shipped in Chrome 97 (2022-01-04), which seems to be a worthy successor to WebSockets [0]. It allows for reliable and unreliable modes which is a problem for games using WebSockets, among other things. [0] https://web.dev/webtransport/

Is this a new standard, or yet another thing Google is pushing and everyone else have to implement?

Linked in OP: https://w3c.github.io/webtransport/

It's a proposal, 2 editors are from Google the other one is from Microsoft.

Re: The WebSocket Handbook

#89

Post by gfd »

twic wrote: post #85

I use websockets quite a lot, for real-time dashboard kind of purposes. The one thing i really wish websockets had is some kind of application-level acknowledgement or backpressure. At the server end, you're blasting out messages to the client, but you have no idea if it is keeping up with them. Most of the time, it will be, but if there is a sudden spike of activity, suddenly all your dashboards are going wild, and…

I don't know anything about websockets, but isn't it over tcp? Meaning if the client isn't keeping up, their buffer should be full and the server should be blocked from sending more until it drains (unless it's queuing the messages somewhere else?). Or is that not how tcp backpressure works?
Post reply on HN