6 ms·
I started with WebSocket over TCP for practical reasons: * Works everywhere today (browsers, LB, PaaS) with zero extra setup. * One upgrade -> binary frames;
by efecan0 1y ago
I started with WebSocket over TCP for practical reasons:
* Works everywhere today (browsers, LB, PaaS) with zero extra setup.
* One upgrade -> binary frames; no gRPC/proto toolchain or HTTP/3 infra needed.
* Simple reliability: TCP handles ordering; I add optional QoS2 on top.
* Lets me focus on session/room/middleware features first; transport is swappable later.
QUIC / gRPC-HTTP/3 is on the roadmap once the higher-level API stabilises.
- seangrogg 1y agoAssuming you're locked in on the browser WebSockets are about as good as it gets at present. HTTP/3 requires WebTransport which has been a bit of a shitshow in terms of getting things up and running so far, in my experience.
- efecan0 1y agoThanks, that matches my experience as well. For browser clients WebSocket is still ‘the path of least pain’, so I’m keeping it as the default. When WebTransport and QUIC become easier to deploy I’ll add an optional transport module. If you’ve tried any recent WebTransport builds and have tips or docs, I’d love to see them—feel free to open an issue or drop a link. Appreciate the confirmation!