graphql-subscriptions
graphql-subscriptions copied to clipboard
Consider suggesting to use Server Sent Events prior to Websockets
Hey,
I would like you to consider using server sent events by default and suggest this approach to the people, as we saw here in a lot of live-examples, that using websockets together with async interators in production could be a very explosive mixture.
https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/
-
Maybe we could together develop a more common solution, which is inspired from: https://github.com/CodeCommission/subscriptions-transport-sse?
-
I am asking myself, why we are forced to use async-iterators as a technology, which seems to be not really ready for production purposes? Is there any alternative?
Cheers!
using websockets together with async interators in production could be a very explosive mixture.
Can you please elaborate more on what these concerns are ? Or provide links to relevant resources.
The linked smashingmag article mentions some issues with websockets in general but I am unclear on what the concerns around async iterators (in particular) are.
@lorefnon IMO a lot of "Async-iterator" Code was duplicated without thinking about the complications, which can occur in production. I am asking myself, if we could create a more general simple to use connector-interface, without getting into trouble by mis-using async-iterator implementations?