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

71–80 of 124 posts

Re: The WebSocket Handbook

#71

Post by twic »

latch wrote: post #38
JSdev1 wrote: post #24

Earlier quoted context omitted.

It's the same thing as HTTP. Websocket starts off as an HTTP request with cookies, headers etc. Use those just like HTTP to authenticate, and your Websocket server should pass the user data to the websocket object

Don't have access to the headers from JS. Best solution might be to generate a short-lived one-time-use ticket and pass it in the querystring.

If you make a normal HTTP request first, the server can issue a standard HTTP cookie to the client. That cookie will then be included when the browser makes the websocket request.

However, websockets are not subject to the same-origin policy, so this exposes you to CSRF [1]. To protect against that, you should check the Origin header on the server side.

[1] https://christian-schneider.net/CrossSiteWebSocketHijacking....

Re: The WebSocket Handbook

#72

Post by lelanthran »

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?

:-)

Re: The WebSocket Handbook

#73

Post by nlitened »

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…

> it can make balancing the WebSocket connections a bit more challenging since they are long lived. Deployments are even more inconvenient since (in our case) we disconnect the WebSocket consumers whenever a server is restarted

May I suggest that the solution could be to design your WS protocol to be reconnect-friendly, like the Phoenix LiveView protocol? Maybe make a protocol which assumes and expects that a connection may be dropped by any side at any time, with robust context-restoration API such as “full snapshot” or “all updates since event ID”

Re: The WebSocket Handbook

#74

Post by scurvy_steve »

hwers wrote: post #15

Anyone know of any examples of cool cases where websockets have been used? (Maybe other than games.) I feel like in most cases I see them used the latency gained is basically added back with bloat in other parts.

I have an app based around some long running resource intensive processes that run on scalable microservices. So you click a button and may have to wait 5+ minutes before you get a response. Websockets let you do notifications and make everything async. They've served me well for request/response that might take 3-30 minutes.

Re: The WebSocket Handbook

#75

Post by Ostrogodsky »

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.

Why does Klopp love to abuse referees and then play dumb?

Re: The WebSocket Handbook

#76

Post by twic »

hwers wrote: post #15

Anyone know of any examples of cool cases where websockets have been used? (Maybe other than games.) I feel like in most cases I see them used the latency gained is basically added back with bloat in other parts.

We use them for a variety of intranet realtime dashboard type things. Both user-facing production UI, where users are looking at screens covered with dozens of dashboards all updating several times a second, and developer-facing monitoring.

The client-side code is generally very simple. A dashboard opens a websocket and attaches a handler which parses the message (all our payloads are JSON), then routes the update to the right bit of the UI. We wrote a thin wrapper round the browser websocket API to handle disconnections. We wrote server-side libraries to support our patterns of use.

I initially did a bunch of developer-facing dashboards using server-sent events, because they're slightly easier to work with. However, websockets have a significant advantage over SSE: you can have a lot more of them open at once. Browsers will limit you to a few (six?) connections per origin, including long-lived SSE connections, whereas you can have dozens or hundreds of websockets open [1]. If you are serving lots of different dashboards off a single server, you rapidly get to the point where this matters!

[1] https://stackoverflow.com/questions/26003756/is-there-a-limi...

Re: The WebSocket Handbook

#77

Post by nurettin »

matt_oriordan wrote: post #52
mwcampbell wrote: post #51

Earlier quoted context omitted.

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…

Sorry to butt in like this, but cloud is just one direction, not the direction. Pretty much any company that values their privacy and independence will want on-prem. This should not come as a surprise to anyone.

Re: The WebSocket Handbook

#78

Post by crummy »

chalas_r wrote: post #64

Mercure is an alternative to WebSocket that is especially useful for REST/GraphQL APIs. It's a protocol that builds on HTTP and Server-Sent Events thus is supported out of the box by browsers, mobile apps and IoT clients, and it doesn't suffer from most WebSocket limitations (e.g. header/cookie based authorization works): https://mercure.rocks

> it doesn't suffer from most WebSocket limitations (e.g. header/cookie based authorization works)

Don't WS connections send headers? What's the limitation here?

Re: The WebSocket Handbook

#79

Post by arendtio »

Does someone know, why Websockets are sometimes considered a security risk and blocked by corporate firewalls, even when the rest of the website is considered to be trustworthy?

Re: The WebSocket Handbook

#80

Post by mathgladiator »

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.

This is one reason I'm making my up and coming SaaS entirely open source, so you can run a clone in any environment: http://www.adama-lang.org/
Post reply on HN