This article is - to me - essentially a list of why SSE/Websockets or any sort of long lasting TCP connection with state is bad. It’s full of scaling problems, it requires a huge amount of connections, it has the problem of “catching up” after a disconnect. And it’s fun to perform WS/SSE with a typical reverse-proxy stack where you terminate http2/TLS at the nginx/apache in front. And it’s the perfect opportunity to DoS every minor service (i.e. not AWS with cloudflare in front to prevent a huge bill). And all that for the sake of my shopping cart updating live..
A mentor warned me not to use Websockets for a website. Basically glorified shopping cart update features. I was like no I’m using gql it’ll be fine. Ended up ripping it out for reasons you outline. Introduced an order of magnitude more complication. Love it for pub/sub for backend stuff though
One could almost think that maybe HTTP isn’t the protocol most suited for PubSub.
This article is - to me - essentially a list of why SSE/Websockets or any sort of long lasting TCP connection with state is bad. It’s full of scaling problems, it requires a huge amount of connections, it has the problem of “catching up” after a disconnect. And it’s fun to perform WS/SSE with a typical reverse-proxy stack where you terminate http2/TLS at the nginx/apache in front. And it’s the perfect opportunity to DoS every minor service (i.e. not AWS with cloudflare in front to prevent a huge bill). And all that for the sake of my shopping cart updating live..
A mentor warned me not to use Websockets for a website. Basically glorified shopping cart update features. I was like no I’m using gql it’ll be fine. Ended up ripping it out for reasons you outline. Introduced an order of magnitude more complication. Love it for pub/sub for backend stuff though