Subscriptions Setting

Subscription operations

GraphQL puts near real-time data, called subscription operations, at the same first-class level as queries or mutations. These subscriptions allow users to request data updates using the same semantics as any other GraphQL request and manage the life cycle of the data feed. Modern user interfaces using subscriptions can work with live data as a part of their normal conversation with a GraphQL server.

Setting up subscriptions

Subscriptions let a client submit a GraphQL document that is executed based on some event in the system instead of being executed immediately. From the server’s perspective, we need to be able to hold onto documents that clients have submitted so we can run them at the right time. We also need a way to propagate events through the system. Finally, we need a way to have a persistent connection with the client so we can push results up to them when their documents are executed.

This requires a little bit of setup. Fortunately, PlateSlate already has Phoenix as a dependency, which will play the publish-subscribe and WebSocket system. This provides several handy features for free. Clients will be able to use long polling or WebSockets. PubSub will work either over the distributed Elixir or through any other adapter built to work with Phoenix PubSub. However, there are a few things you need to do to connect these capabilities to Absinthe.

The first order of business is to add an Absinthe.Subscription supervisor to the PlateSlate application’s supervision tree by modifying the children list in the start/2 callback of application.ex: