Chapter 6
Going Live with Subscriptions

In REST-oriented web frameworks, the need to have near real-time, live data streams still feels like a strange new world. It isn’t necessarily that setting up a WebSocket connection is hard (particularly if you’re using Phoenix), but rather that such connections don’t fit into the REST API paradigm very easily. Setting up connections for specific data feeds and managing the communication across them is, to say the least, awkward in a world of “resources” tightly coupled to HTTP verbs. Consequently, even in frameworks that have fantastic near real-time support, whatever approach that’s available doesn’t feel like a first-class part of the API. When your API is built solidly around the semantics of HTTP requests, the needs of live data feeds can feel like an afterthought.

GraphQL, on the other hand, puts near real-time data at the same first-class level as queries or mutations with what are called subscription operations. It’s these subscriptions that 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. Near real-time data updates are not a bolt-on, after-market component of a GraphQL API, but rather an intrinsic feature.

Over the last few chapters, we’ve built up the foundation of a GraphQL API for a restaurant menu and ordering system. Our example application, PlateSlate, is just crying out for user interfaces that use near real-time data. Whereas something like the restaurant menu is a relatively static set of information, orders are dynamic. From a screen in the restaurant’s fast-moving kitchen that tells cooks when and what to prepare, to consumer mobile applications that support to-go and delivery ordering, it’s important that information about changes to an order’s status is distributed quickly and easily.

We’ll spend this chapter building a simple system for tracking orders in a specific restaurant. The scenario will go like this:

• The customer goes to a cashier, orders and pays for items, and is handed a number.

• A user interface in the restaurant kitchen displays the order as it is placed, along with what items are in the order.

• A simple status screen is displayed in the seating area of the restaurant, letting the customer know when their order is ready for pickup.

• When their food is ready, the customer trades in the number for their food.

In this chapter, you’ll learn how to model the related data operations and configure the subscriptions that will power these user interfaces. Let’s get started by covering some important background about subscriptions.