Imagine that we want to serve a web application to thousands of users. The information on the page should stay up to date even if the user does not actively refresh the page. At the moment, we have two ways to achieve this:
- Setup subscriptions to the data that may change via GraphQL
- Setup periodic queries to GraphQL on a loaded page
Here are some thoughts:
- A change in the data should be visible to the client after maximum 30s. So periodic queries would need to run every 30s at least.
- Let's say 1000 users have our page open at the same time, even if they are not actively looking at it. If we query every 30s, that will generate a base load of 33.3 queries/second even if nobody actively requests a new view or refreshes.
- On the "worst" view, there are maybe 60 data points that would individually update via subscriptions. So 1000 open tabs would be 60k open subscriptions.
We are wondering which solution scales better / is recommended.
- Is it best to have thousands of subscriptions running (essentially thousands of open TCP sockets powering the websocket connections) or is it better to query again and again for barely changing data?
- How big is the "steady-state"/"heartbeat" load of the open websocket connections for the subscriptions?
- From a server perspective, will the open websockets or the periodic queries require more CPU load for the GraphQL server?
If you have experience with such a trade-off, it would be great if you could share it.