does this still work with a current version of apollo?

[boredland]

Since this transport plugin has been last updated 2 years ago, I'm wondering if this is a feasable solution for a websocket-alternative.

[MikeBild]

No, the current Apollo API is completely different. It doesn't work with the current version of apollo.

[ivosabev]

Why is this not maintained and updated for the latest Apollo API, since SSE is in most cases superior to WebSocket?

[pascoual]

Need to apply all changes from this commit : https://github.com/apollographql/subscriptions-transport-ws/commit/d9ce607709feca19dd0ba743e77c135af9b0298e#diff-b9cfc7f2cdf78a7f4b91a753d10865a2

[pascoual]

Need to take a look at : https://github.com/scivisum/subscriptions-transport-sse

[wmertens]

I took a look at these, the commit only converts from executionIterable to executionPromise, a small change. The scivisum fork doesn't seem to include anything that would make it compatible with Apollo again, and it adds the requirement that requests are passed via the url.

I'd prefer a system where you set up an SSE stream (or multiple) for getting results, and when you post the subscription query, you start getting the results in the stream. To know which stream to post to, you can use a secret token that you receive when opening the stream and then pass it to the server via a cookie (technical cookie excempt from cookie law), a header, or even an unused query variable.

[wmertens]

I also don't think subscription-transport-ws should be taken as a role model. It has to implement a separate server whereas the approach above should only provide a resolver for subscriptions (in theory). The SSE channel can be managed by an apollo-link, which could probably create the channel just before a subscription request is sent.

[iambumblehead]

@wmertens I'm investigating this area of graphql and your idea seems great.

I wonder why graphql is designed in such a way prevent usage of SSE

[wmertens]

@iambumblehead actually I'm pretty close to having it working, right now I'm stuck trying to get the subscribe observer working. The channel auto-setup and message passing seems good so far.

[Jon-Shyu]

For anyone else interested, I got this working via graphql-helix and sse-z (a bit outdated and needs some tweaks)

See the Subscriptions over SSE recipe: https://github.com/contrawork/graphql-helix Client library: https://github.com/danielrearden/sse-z

Essentially just adds the operation name, variables, etc as query params to the EventSource URL

The next question now is, is there anything available for our iOS/Android friends? It would suck for them to also have to write their own client libraries when the Apollo docs have such strong support for websockets

[wmertens]

I got the subscribe observer working but I still have to handle a lot of connection loss edge cases.

I'm also not sure how to communicate stopping the subscription but I guess none of the clients have that?

[wmertens]

@Jon-Shyu nice! but I wonder what the limit is on concurrent SSE channels for a single site?

[legopin]

Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, which means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com (per Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#receiving_events_from_the_server