This is not related to GraphQL.
> Also, SSEs add a lot of overhead because you need to authenticate each SSE channel independently (unlike with WebSockets where you only need authenticate a socket once at the beginning)
I wouldn't consider this a lot of overhead. You're re-using an open TCP connection. You have to send a token which needs to be validated, sure. That's a sub millisecond overhead.
> In general, SSE authentication is tricky and forces you to rely on cookies
You can send a token as query parameter. Using TLS this is no different than a Header.
> Moreover, the lack of control over the lifecycle of the SSE connection makes it difficult to coordinate recovery from network or server failure/restart; a common problem happens when your server crashes and then all the SSE event sources try to reconnect immediately at the same time and this DDoSes your server again, then the reboot and crash cycle repeats indefinitely... With WebSockets, you can control the reconnect algorithm to add exponential backoff (can be customized to your exact requirements).
The EventSource API allows you to close the connection at any time. It will automatically reconnect which I consider a feature. There's also a "onopen" and "onerror" callback. You can use these to control reconnect behaviour and implement an exponential backoff strategy.
I don't see the difference between WebSockets and SSE in case of a server Crash. Both will reconnect and DDos the server.
> SSEs are not a practical abstraction IMO. It's sad that people don't realize how good the WebSocket standard is. It's good because it's simple; it's also why it's so flexible. WebSockets covers more use cases.
You're absolutely right. However, we don't need this flexibility for GraphQL Subscriptions.
I feel like what you're saying makes sense in general. However, in the use case of GraphQL Subscriptions I don't see advantages using WebSockets over SSE.