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

51–60 of 124 posts

Re: The WebSocket Handbook

#51

Post by mwcampbell »

ddoolin wrote: post #8
clone1018 wrote: post #6

We use WebSockets in two regards: handling live page updates via Phoenix Live View for users (eg: real time chat messages, viewer count, etc) and as a transport medium for our real time API. The former is very easy to handle because for the most part users are navigating around pages which can terminate the ws connection and creates a new one (though most of the times not). The advantages Live View provides us is not…

I think your last paragraph is a good point for using services like the OP. All three of the examples you mentioned are already solved. Granted, you're buying into their paradigm particularly regarding communication model but that's a small price to pay for the upsides. Disclaimer: we've been using Ably for years and their service and reliability has been outstanding, and we have worked closely with their engineers a…

I'm generally reluctant to add dependencies on third-party services such as Ably in the core application, because that would add another barrier to providing an on-prem deployment option, or even allowing a customer to deploy on their own AWS infrastructure instead of ours. I'm actually contemplating this decision right now for a new product.

Re: The WebSocket Handbook

#52

Post by matt_oriordan »

mwcampbell wrote: post #51
ddoolin wrote: post #8

Earlier quoted context omitted.

I think your last paragraph is a good point for using services like the OP. All three of the examples you mentioned are already solved. Granted, you're buying into their paradigm particularly regarding communication model but that's a small price to pay for the upsides. Disclaimer: we've been using Ably for years and their service and reliability has been outstanding, and we have worked closely with their engineers a…

I'm generally reluctant to add dependencies on third-party services such as Ably in the core application, because that would add another barrier to providing an on-prem deployment option, or even allowing a customer to deploy on their own AWS infrastructure instead of ours. I'm actually contemplating this decision right now for a new product.

I am surprised to hear about on-prem deploys when the direction of travel is towards serverless/cloud solutions that don't require orchestration. Out of interest, why is on-prem so important for your use case? Separately, I'd be interested in how you'd view that decision if there was a less scalable but mostly fully functioning open source version of the third-party service you could deploy if you needed to?

Matt, co-founder of Ably

Re: The WebSocket Handbook

#53

Post by httgp »

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.

Is Ably playing with WebTransport? If it moves up from its current trial status, how do you see that changing Ably’s core?

Re: The WebSocket Handbook

#54

Post by matt_oriordan »

ddoolin wrote: post #8
clone1018 wrote: post #6

We use WebSockets in two regards: handling live page updates via Phoenix Live View for users (eg: real time chat messages, viewer count, etc) and as a transport medium for our real time API. The former is very easy to handle because for the most part users are navigating around pages which can terminate the ws connection and creates a new one (though most of the times not). The advantages Live View provides us is not…

I think your last paragraph is a good point for using services like the OP. All three of the examples you mentioned are already solved. Granted, you're buying into their paradigm particularly regarding communication model but that's a small price to pay for the upsides. Disclaimer: we've been using Ably for years and their service and reliability has been outstanding, and we have worked closely with their engineers a…

Thanks ddoolin. I am not sure which company you are, but I appreciate your comments and even more happy to hear you feel we're doing a fantastic job! You've sort of encapsulated why we exist: we know software engineers can build and run all sorts of things on their own i.e. we're not the only option from open source solutions to custom builds. However, we built Ably to be the easiest, most scalable, and reliable realtime option which for developers that removes complexity and helps them manage costs as they grow (pay for what you use).

Matt, co-founder at Ably

Re: The WebSocket Handbook

#55

Post by matt_oriordan »

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/

I know, we're very excited about WebTransport and what it can offer. As you say, on the surface it seems to provide both a more performant and reliable transport for realtime communications. Once it hits mainstream, we'll be certainly adding it as another transport we support in our stack (currently websockets, HTTP, SSE, MQTT etc)

Matt, co-founder of Ably

Re: The WebSocket Handbook

#56

Post by matt_oriordan »

httgp wrote: post #53
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.

Is Ably playing with WebTransport? If it moves up from its current trial status, how do you see that changing Ably’s core?

We are monitoring it closely and super excited about what WebTransport will provide, which is both a more reliable and in many cases more performant transport. However, much like WebSockets, it's still quite low level and only provides a basic communication protocol. As such, like we have done with SSE, HTTP, Websockets and MQTT, our service focusses on what developers can enable on top of these lower level transports, such as presence, deltas, history of streams, limitless scale and fan-out of data, and the list goes on https://ably.com/platform.

When WebTransport reaches prime time, I'm confident we'll be supporting it.

Re: The WebSocket Handbook

#57

Post by PaulDavisThe1st »

keithwinstein wrote: post #48
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.

I think it mostly has to do with: 1) the large "implementation surface" of three components (TLS+HTTP+WebSocket), each of which by itself requires an API more complicated, if provided by a userspace library, than a kernel-provided TCP socket, and maybe 2) the fact that non-Web servers are rare enough, and WebSockets are still recent enough, that no "standard" library has emerged and had its edges honed down over time…

Thanks for that very clear and informative answer.

We ended up using libwebsockets and it's fine. It runs in its own thread and the rest of the code doesn't have to care much about it. It would have been nice to just use the socket directly from liblo (OSC library), but the current arrangement seems perfectly OK.

Re: The WebSocket Handbook

#58

Post by matt_oriordan »

hammersmith wrote: post #41
superasn wrote: post #39

Earlier quoted context omitted.

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…

Have a look at https://m-ld.org/ , its a CRDT implementation that's all Javascript. it could help

Yup, and it supports Ably too, see https://js.m-ld.org/#ably-remotes!

Matt, Ably co-founder

Re: The WebSocket Handbook

#59

Post by matt_oriordan »

capableweb wrote: post #36
AlexTDiaconu wrote: post #19

Earlier quoted context omitted.

As with REST APIs, you'd want to be able to authenticate to a websocket-based API using either basic auth, or a bearer token-based auth scheme. Unfortunately, the browser websocket API doesn't allow you to specify arbitrary headers in the websocket request, so it's typical instead to have credentials supplied via a query param (such as "accessToken" for a bearer token) in the wss request.

> so it's typical instead to have credentials supplied via a query param (such as "accessToken" for a bearer token) in the wss request. If someone ends up actually doing this in a production system, remember to not to log the accessToken if you're logging full paths/URIs somewhere, as query params usually is a part of that type of logging.

Yup, true, although tokens should be ephemeral so less of a risk. Authenticating inline over the Websocket connection is valid too, but it does expose the socket connections to slightly more surface area of attack i.e. if you pass in a token as a param, the Websocket request can be rejected immediately. If however you authenticate after establishing a Websocket connection, then there is an attack vector where you simply open Websocket connections and never authenticate. Of course timeouts can be used to disconnect rogue actors, but it is a consideration.

Matt, Ably co-founder

Re: The WebSocket Handbook

#60

Post by matt_oriordan »

e1g wrote: post #27
paddybyers wrote: post #12

Earlier quoted context omitted.

Disclaimer: I work for Ably. I agree in principle, so the libraries that handle websockets and also fallback transports using comet (eg SocketIO) are still widely used for that reason, and the commercial pub/sub service providers generally also support comet fallbacks. However, we now find that it is really very rare that clients are unable to use wss.

WSS breaking is surprisingly common for clusters of our enterprise users, to the order of 5-10%. Specifically, when business users connect through security networks like Zscaler, often their employers will MITM all connections (similar to how AdGuard works) but in a way that breaks WSS. We have rigorous monitoring for both frontend and backend, and can trace these failures with accuracy - consistently, both the front…

That's surprising to hear, we definitely don't see anywhere near the order of 5-10%, at best on order of magnitude less.

Out of interest, what geography and industries are you operating in where you see such a high rate of incompatibiltiy?

Matt, Ably co-founder

Post reply on HN