Live data from Hacker News

The WebSocket Handbook

ably.com

101–110 of 124 posts

Re: The WebSocket Handbook

#101
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…

It is better to implement it at front end. Actually it is not better it is kinda has to be that way. Because page will be already lagging and if you implement it at front at there won't be any lags. And it is better to have limits about update frequency at the back-end. If reactor temperature already announced 100 ms ago and it went to 1051K from 1050K maybe it is better to delay it for a second.

Re: The WebSocket Handbook

#102

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

I love Server-Sent Events, but just as a heads up in case anyone doesn't know there are some limitations to SSE:

* Doesn't natively support binary data.

* If you're using HTTP/1.1 in the browser, you'll be severely limited in the number of SSE connections you can have going at a time. If you're on HTTP/2 then it's not a problem.

Re: The WebSocket Handbook

#103
post #90

Does anyone know when to choose http2 vs websockets?

I'm assuming you mean HTTP/2 with Server-Sent Events, since raw HTTP/2 frames aren't exposed in the browser?

My answer would be use HTTP/2 + SSE whenever you can get away with it. The primary limitation of SSE in this case is you can't natively send binary data (you would have to base64 encode it or something). If you're just using JSON or another text format anyway this isn't an issue.

Re: The WebSocket Handbook

#104
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'll throw my hat in the ring: https://iobio.io/2019/06/12/introducing-fibridge/

Re: The WebSocket Handbook

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

Just this past weekend, I created a service for transferring files that is built on websockets ( https://qr.dibble.codes / https://github.com/acdibble/qr-transfer ). It's still rough and very MVP, but it's functional. My use case was I wanted to transfer a PDF to an Android-based tablet but in the moment didn't want to log into my email. I couldn't think of any quick, easy, and cross-platform solutions so I decided t…

[deleted]

Re: The WebSocket Handbook

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

Just this past weekend, I created a service for transferring files that is built on websockets ( https://qr.dibble.codes / https://github.com/acdibble/qr-transfer ). It's still rough and very MVP, but it's functional. My use case was I wanted to transfer a PDF to an Android-based tablet but in the moment didn't want to log into my email. I couldn't think of any quick, easy, and cross-platform solutions so I decided t…

Nice! I'm curious what you think of https://patchbay.pub.

Re: The WebSocket Handbook

#107
Anyone looked at the book? I feel a little bit spammed by this post. The linked page is a pitch for an ebook that is a free download, but you have to sign up for promotional mailings in order to get it, and they want your first and last name. Yes you can unsubscribe but this is still obnoxious. A direct link to a pdf would be much more attractive.

I haven't programmed anything with websockets yet, but I read the wikipedia page about them recently and found it sufficient to understand what they were. The rest is a matter of javascript programming that I've avoided messing with so far.

Re: The WebSocket Handbook

#108

A couple months ago I posted the "Implementer's guide to WebSockets" that I wrote, but it seemingly got shadowbanned. [1] I wrote the guide with example code for people wanting to know how to implement the complete WS13 protocol from scratch, so you can try it out, fiddle around and modify it to your needs. The guide is more in-depth and assumes that the reader is willing to read the RFC when they're stuck :) [1] htt…

This looks nice. I think I'll start with it instead of the OP ebook. Thanks for writing and posting it.

Re: The WebSocket Handbook

#109

Anyone looked at the book? I feel a little bit spammed by this post. The linked page is a pitch for an ebook that is a free download, but you have to sign up for promotional mailings in order to get it, and they want your first and last name. Yes you can unsubscribe but this is still obnoxious. A direct link to a pdf would be much more attractive. I haven't programmed anything with websockets yet, but I read the wiki…

I just provide a spam email account for things like this.

I have yet to read through it much, but it is interesting.

https://files.ably.com/website/documents/ebook/the-websocket...

Re: The WebSocket Handbook

#110

A couple months ago I posted the "Implementer's guide to WebSockets" that I wrote, but it seemingly got shadowbanned. [1] I wrote the guide with example code for people wanting to know how to implement the complete WS13 protocol from scratch, so you can try it out, fiddle around and modify it to your needs. The guide is more in-depth and assumes that the reader is willing to read the RFC when they're stuck :) [1] htt…

This is pretty excellent. I'll hold on to both of these resources as I think websockets would be just wonderful for the work I'm doing right now.

> willing to read the RFC when they're stuck :)

I owe RFCs for just about everything I do, they play a small but necessary role, I can't imagine not wanting to dip into one of them even if you aren't stuck.

Post reply on HN