Why would you choose Server-Sent Events over WebSockets as GraphQL transport?

[FluorescentHallucinogen]

@MikeBild Could you please add a something like "Server-Sent Events vs. WebSockets (pros and cons)" section to the README.md?

[dandv]

Great idea. I was wondering myself why SSEs aren't the default over WebSockets for GraphQL subscriptions. Some advantages (this article has more):

1. Lower resource consumption
2. The browser reconnects automatically
3. WebSockets may be blocked in some instances, SSEs are just HTTP
4. SSEs are supported by HTTP/2, WebSockets are not

CC @stubailo

[NeoPhi]

Another article talking about the differences and advantages of SSE:
https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/

[mrdulin]

For me, because GCP app engine does not support Websockets.

[TimSusa]

IMO this approach is totally under-represented and I cannot understand this. People using subscriptions should ask themselves, if they need a ninja engine in their shopper or is the native engine not enough to drive along? I mean, why suffering from all the hazzle with websockets and using another protocol beneath? IMO SSE is standardised and smart enough for common use cases.

[wmertens]

One more reason: SSE works just fine on AWS Lambda. A lambda can run for 5 minutes, and SSE auto-reconnects, so you get automatic load balancing as well. No need for a complex websockets via AWS IoT setup.