In the majority of cases, your client should not use subscriptions to stay up to date with your backend. Instead, you should poll intermittently with queries, or re-execute queries on demand when a user performs a relevant action (such as clicking a button).
You should use subscriptions for the following:
Small, incremental changes to large objects. Repeatedly polling for a large object is expensive, especially when most of the object’s fields rarely change. Instead, you can fetch the object’s initial state with a query, and your server can proactively push updates to individual fields as they occur.
Low-latency, real-time updates. For example, a chat application’s client wants to receive new messages as soon as they’re available.
I’d like a definitive answer on WHY. Why not use subscriptions for everything?
Hello! Thanks for identifying this gap in the docs. One of the biggest reasons to favor queries over subscriptions when possible is that a query is a short-lived, stateless operation, whereas a subscription is a long-lived, stateful operation that’s usually attached to a particular server instance for its duration.
Supporting subscriptions is a significant change for any GraphQL service. Query and mutation operations are stateless, allowing scaling via cloning of GraphQL service instances. Subscriptions, by contrast, are stateful and require maintaining the GraphQL document, variables, and other context over the lifetime of the subscription.
Consider the behavior of your system when state is lost due to the failure of a single machine in a service. Durability and availability may be improved by having separate dedicated services for managing subscription state and client connectivity.
This would mean that if your GraphQL server runs on a server platform specifically designed for millions of long-lived connections (such as Erlang/Elixir), this assertion would not hold. And therefor there would be no reason not to use subscriptions for everything.