| >> I wouldn't consider this a lot of overhead. Depends on how many subscriptions you want. If you have 100s of subscriptions, it can add up. >> You can send a token as query parameter. If using JWT or some other kind of stateless signed (or encrypted) token, that would take up a large part of the URL. Also URL length is limited to around 2000 characters in some browsers. So it encourages short session IDs instead of signed tokens (session IDs are not stateless; so it's going to force an additional database call to be made on the server-side). >> The EventSource API allows you to close the connection at any time. It will automatically reconnect which I consider a feature. Yes there is some control. But if it auto-reconnects too fast, then your servers could end up DDoSed if you had a lot of concurrent clients. If it auto-reconnects too slow, then your users could miss more messages than would be desirable depending on the use case. With WebSockets, you can control the backoff to your needs and you can randomize, so you can ensure that not all clients try to reconnect at the exact same time; you can tailor it to your architecture. >> However, we don't need this flexibility for GraphQL Subscriptions. It seems like it simplifies things but also potentially reduces flexibility and performance. But I'm not familiar with the typical use case for GraphQL so maybe it's worth it. |