Hot schema reloading

This example demonstrates reloading the combined gateway schema without restarting its server; a technique commonly known as a “hot” reload. This allows service schemas to be dyanmically added, removed, or updated in response to administrative actions or changes in service health.

This example demonstrates:

• Hot reload of the gateway schema (no server restart).
• Polling for remote subschema changes.
• Mutations for dynamically adding/removing subservices.
• Handling subservice request timeouts.

Related examples:

• See versioning schema releases for more ideas on versioning and reloading.

Sandbox

⬇️ Click ☰ to see the files

You can also see the project on GitHub here.

The following services are available for interactive queries:

• Stitched gateway: listening on 4000/graphql
• Inventory subservice: listening on 4001/graphql
• Products subservice: listening on 4002/graphql

Summary

Visit the stitched gateway and try running the following query:

query {
  endpoints {
    url
    sdl
  }
}

Then, try the following mutation:

mutation {
  removeEndpoint(url: "http://localhost:4001/graphql") {
    success
  }
}

Refresh gateway GraphiQL and see how the available types and root fields automatically adjust after the Reviews service has been removed from the gateway.

Then, try the following mutation:

mutation {
  addEndpoint(url: "http://localhost:4001/graphql") {
    success
    endpoint {
      url
      sdl
    }
  }
}

Refresh gateway GraphiQL and see how the available types and root fields have been restored.

Without polling

Polling is by no means necessary to trigger gateway schema reloads. An even simpler solution is to setup a dedicated mutation that reloads the gateway schema, and then call it manually or in response to deployment hooks. Try running the reloadAllEndpoints mutation in this example to manually trigger a reload:

mutation {
  reloadAllEndpoints {
    success
  }
}

See versioning schema releases for a deeper exploration of hot-reloads that fetch from a versioned schema registry.

Dropping services

This configuration can also handle dropping services when they go offline. To try it, run each service in thier own terminal window:

# first terminal:
yarn start-service-inventory
 
# second terminal:
yarn start-service-products
 
# third terminal:
yarn start-gateway

Now try stopping the Products service by exiting its program (CTRL+C). Refresh gateway GraphiQL and notice that the schema has responded to the change automatically.