| Websocket is definitely a superior abstraction, but the main problem with it is that a lot of corporate firewalls/network proxies don't know how to handle the upgrade request and drop the connection. We took a dependency on Websockets a few years back and while everything worked fine in the US, a lot of our customers in Asia/Europe simply couldn't access some of the core functionality of our site. The Server-sent-events/EventSource API _seems_ like a better fit for GraphQL subscriptions because it's one-directional traffic anyway, but in addition to the issues you mentioned above, you'll also run into the 2000-character limit most browsers have for URLs [1]. The browser's EventSource constructor does not let you specify request bodies so you're forced to put everything in the URL, which is _not_ suited for the graphql queries which tend to get pretty large. I ended up writing an alternate EventSource parser using the fetch() api [2] to get around this limitation. Happily, there seems to be two alternate approaches in the pipeline that seem more robust/better supported: 1. The proposed @defer graphql directive [3] recommends using multi-part HTTP as the standard transport layer, so hopefully all the tooling like GraphQL Playground will support a single-request-multiple-response scenario over plain HTTP 2. For scenarios where we need interactive, bidirectional communication, the proposed WebTransport API [4] seems to solve some of the issues with websockets. [1] https://stackoverflow.com/a/417184 [2] https://github.com/Azure/fetch-event-source [3] https://www.apollographql.com/docs/react/v2.4/features/defer... [4] https://github.com/WICG/web-transport |
The link about the @defer implementation looks very interesting. Thanks for posting this.