GraphQL subscriptions with a cloud supergraph

Cloud supergraphs provide preview support for GraphQL subscription operations:

1
subscription OnStockPricesChanged {
2
  stockPricesChanged {
3
    symbol
4
    price
5
  }
6
}

With a cloud supergraph, you can add Subscription fields to the schema of any subgraph that supports the graphql-transport-ws WebSocket protocol:

1
type Subscription {
2
  stockPricesChanged: [Stock!]!
3
}

Clients can then execute subscriptions on your cloud router, which executes them on your subgraphs.

What are subscriptions for?

GraphQL subscriptions enable clients to receive continual, real-time updates whenever new data becomes available. Unlike queries and mutations, subscriptions are long-lasting. This means a client can receive multiple updates from a single subscription:

Subscriptions are best suited to apps that rely on frequently-changing, time-sensitive data (such as stock prices, IoT sensor readings, live chat, or sports scores).

How it works

1. A client executes a GraphQL subscription operation against your cloud router over HTTP:

   GraphQL

   Example subscription

   1
   subscription OnStockPricesChanged {
   2
     stockPricesChanged {
   3
       symbol
   4
       price
   5
     }
   6
   }

   Copy
   • The client does not use a WebSocket protocol! Instead, it receives updates via multipart HTTP responses.
   • By using HTTP for subscriptions, clients can execute all GraphQL operation types over HTTP instead of using two different protocols.
   • Apollo Client for Web, Kotlin, and iOS all support GraphQL subscriptions over HTTP with minimal configuration. See each library's documentation for details.

2. When your cloud router receives a subscription, it executes that same subscription against whichever subgraph defines the requested field (stockPricesChanged in the example above).

   • This communication does use a WebSocket subprotocol (specifically, graphql-transport-ws).

3. The subgraph periodically sends new data to your router. Whenever it does, the router returns that data to the client in an additional HTTP response part.

   • A subscription can include federated entity fields that are defined in other subgraphs. If it does, the router first fetches those fields by querying the corresponding subgraphs (such as Portfolios in the diagram above). These queries use HTTP as usual.

Prerequisites

⚠️ Before you add Subscription fields to your subgraphs, do all of the following in the order shown to prevent errors:

1. Make sure you've created a cloud supergraph and connected your GraphQL API to it!

2. Update your supergraph's build pipeline to use Apollo Federation 2.4 or later.

   • Previous versions of Apollo Federation don't support subscription operations.

3. If your subgraph schemas specify an Apollo Federation version, modify them to use Apollo Federation 2.4 or later:

   GraphQL

   stocks.graphql

   1
   extend schema
   2
   @link(url: "https://specs.apollo.dev/federation/v2.4", 
   3
         import: ["@key", "@shareable"])
   4
   
   5
   type Subscription {
   6
     stockPricesChanged: [Stock!]!
   7
   }

   Copy
   • You can skip modifying subgraph schemas that don't define any Subscription fields.

4. In each subgraph with subscriptions, make sure the subgraph uses the graphql-transport-ws WebSocket protocol for subscriptions.

5. In each subgraph with subscriptions, make sure the subgraph hosts its subscriptions WebSocket endpoint at the path /ws.

   • If your WebSocket endpoint is currently hosted at a different path, you can add /ws as an additional path instead of removing the original path. This is helpful if legacy clients will continue executing subscriptions on your subgraph directly using the original path.

6. Deploy your updated subgraphs.

After you complete these prerequisites, you begin executing subscriptions on your cloud router.

Example execution

Let's say our supergraph includes the following subgraphs and partial schemas:

type Product @key(fields: "id") {
  id: ID!
  name: String!
  price: Int!
}

type Subscription {
  productPriceChanged: Product!
}

type Product @key(fields: "id") {
  id: ID!
  reviews: [Review!]!
}

type Review {
  score: Int!
}

A client can execute the following subscription against our router:

1
subscription OnProductPriceChanged {
2
  productPriceChanged {
3
    # Defined in Products subgraph
4
    name
5
    price
6
    reviews {
7
      # Defined in Reviews subgraph!
8
      score
9
    }
10
  }
11
}

When our router receives this operation, it executes a corresponding subscription operation against the Products subgraph (over a new WebSocket connection):

1
subscription {
2
  productPriceChanged {
3
    id # Added for entity fetching
4
    name
5
    price
6
    # Reviews fields removed!
7
  }
8
}

At any point after the subscription is initiated, the Products subgraph might send updated data to our router. Whenever this happens, the router does not immediately return this data to the client, because it's missing requested fields from the Reviews subgraph!

Instead, our router executes a standard GraphQL query against the Reviews subgraph to fetch the missing entity fields:

1
query {
2
  _entities(representations: [...]) {
3
    ... on Product {
4
      reviews {
5
        score
6
      }
7
    }
8
  }
9
}

After receiving this query result from the Reviews subgraph, our router combines it with the data from Products and returns the combination to the subscribing client.

Trying subscriptions with curl

To quickly try out HTTP-based subscriptions without setting up an Apollo Client library, you can execute a curl command against your cloud router with the following format:

1
curl 'https://main--my-org-supergraph.apollographos.net/graphql' -v \
2
  -H 'accept: multipart/mixed; boundary="graphql"; subscriptionSpec=1.0, application/json' \
3
  -H 'content-type: application/json' \
4
  --data-raw '{"query":"subscription OnProductPriceChanged { productPriceChanged { name price reviews { score } } }","operationName":"OnProductPriceChanged"}'

This command creates an HTTP multipart request and keeps an open connection that receives new subscription data in multiple response parts:

1
--graphql
2
content-type: application/json
3

4
{}
5
--graphql
6
content-type: application/json
7

8
{"payload":{"data":{"productPriceChanged":{"name":"Croissant","price":400,"reviews":[{"score":5}]}}}}
9
--graphql
10
content-type: application/json
11

12
{"payload":{"data":{"productPriceChanged":{"name":"Croissant","price":375,"reviews":[{"score":5}]}}}}
13
--graphql
14
content-type: application/json
15

16
{"payload":{"data":{"productPriceChanged":{"name":"Croissant","price":425,"reviews":[{"score":5}]}}}}
17
--graphql--