View Source Absinthe.Subscription (absinthe v1.7.0)
Real time updates via GraphQL
For a how to guide on getting started with Absinthe.Subscriptions in your phoenix
project see the Absinthe.Phoenix package.
Define in your schema via Absinthe.Schema.subscription/2
Basic Usage
Performance Characteristics
There are a couple of limitations to the beta release of subscriptions that are worth keeping in mind if you want to use this in production:
By design, all subscription docs triggered by a mutation are run inside the mutation process as a form of back pressure.
At the moment however database batching does not happen across the set of subscription docs. Thus if you have a lot of subscription docs and they each do a lot of extra DB lookups you're going to delay incoming mutation responses by however long it takes to do all that work.
Before the final version of 1.4.0 we want
- Batching across subscriptions
- More user control over back pressure / async balance.
Link to this section Summary
Link to this section Types
Specs
Link to this section Functions
Specs
publish( Absinthe.Subscription.Pubsub.t(), term(), Absinthe.Resolution.t() | [subscription_field_spec()] ) :: :ok
Publish a mutation
This function is generally used when trying to publish to one or more subscription fields "out of band" from any particular mutation.
Examples
Note: As with all subscription examples if you're using Absinthe.Phoenix pubsub
will be MyAppWeb.Endpoint.
Absinthe.Subscription.publish(pubsub, user, [new_users: user.account_id])# publish to two subscription fields
Absinthe.Subscription.publish(pubsub, user, [
new_users: user.account_id,
other_user_subscription_field: user.id,
])Add Absinthe.Subscription to your process tree.