Subscriptions Triggers
Learn how to use GraphQL to trigger subscriptions.
We'll cover the following...
Introduction to trigger subscriptions
Since we have already built our context and schema, we can jump directly to building the relevant mutation fields in the GraphQL schema and filling out each resolver.
mutation dofield :ready_order, :order_result doarg :id, non_null(:id)resolve &Resolvers.Ordering.ready_order/3endfield :complete_order, :order_result doarg :id, non_null(:id)resolve &Resolvers.Ordering.complete_order/3end# «Other fields»end
Our :ready_order
and :complete_order
fields use new resolver functions from PlateSlateWeb.Resolvers.Ordering
. Let’s add those:
def ready_order(_, %{id: id}, _) doorder = Ordering.get_order!(id)with {:ok, order} <- Ordering.update_order(order, %{state: "ready"}) do{:ok, %{order: order}}else{:error, changeset} ->{:ok, %{errors: transform_errors(changeset)}}endenddef complete_order(_, %{id: id}, _) doorder = Ordering.get_order!(id)with {:ok, order} <- Ordering.update_order(order, %{state: "complete"}) do{:ok, %{order: order}}else{:error, changeset} ->{:ok, %{errors: transform_errors(changeset)}}endend
Subscribing to these events is slightly different from before because now we’re trying to handle events for specific orders based on ID. When the client is notified about new orders by a new_order
subscription, we want to allow them to subscribe to future updates for each subscription.
We want to support a GraphQL document that looks like this:
subscription {updateOrder(id: "13") {customerNumberstate}}
Notably, we want to use this one subscription field to get updates triggered by both the :ready_order
and :complete_order
mutation fields. While it’s important to represent the mutations as different fields, we often just need a single subscription that lets us get all the state changes for ...