Subscriptions allow GraphQL clients to observe specific events and receive updates from the server when those events occur. This supports live updates, such as websocket pushes. Subscriptions introduce several new concepts:

• The Subscription type is the entry point for subscription queries
• Subscription classes are resolvers for handing initial subscription requests and subsequent updates
• Triggers begin the update process
• The Implementation provides application-specific methods for executing & delivering updates.
• Broadcasts can send the same GraphQL result to any number of subscribers.

Subscription Type

subscription is an entry point to your GraphQL schema, like query or mutation. It is defined by your SubscriptionType, a root-level GraphQL::Schema::Object.

Read more in the Subscription Type guide.

Subscription Classes

GraphQL::Schema::Subscription is a resolver class with subscription-specific behaviors. Each subscription field should be implemented by a subscription class.

Read more in the Subscription Classes guide

Triggers

After an event occurs in our application, triggers begin the update process by sending a name and payload to GraphQL.

Read more in the Triggers guide.

Implementation

Besides the GraphQL component, your application must provide some subscription-related plumbing, for example:

• state management: How does your application keep track of who is subscribed to what?
• transport: How does your application deliver payloads to clients?
• queueing: How does your application distribute the work of re-running subscription queries?

Read more in the Implementation guide or check out the ActionCable implementation, Pusher implementation or Ably implementation.

Broadcasts

By default, the subscription implementations listed above handle each subscription in total isolation. However, this behavior can be optimized by setting up broadcasts. Read more in the Broadcast guide.

Multi-Tenant

See the Multi-tenant guide for supporting multi-tenancy in GraphQL subscriptions.