{"id":13726857,"url":"https://github.com/apollographql/supergraph-demo","last_synced_at":"2026-05-28T01:07:38.966Z","repository":{"id":37356708,"uuid":"353215454","full_name":"apollographql/supergraph-demo","owner":"apollographql","description":"🍿 Compose subgraphs into a Federation v1 supergraph at build-time with static composition to power a federated graph router at runtime.","archived":false,"fork":false,"pushed_at":"2025-05-04T11:13:52.000Z","size":5500,"stargazers_count":143,"open_issues_count":24,"forks_count":45,"subscribers_count":13,"default_branch":"main","last_synced_at":"2025-05-04T12:24:29.104Z","etag":null,"topics":["apollo","apollo-federation","cloud-native","composition","federated-graph","federation","gateway","gitops","graph-router","graphql","kubernetes","schema","schema-checks","subgraph","supergraph"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/apollographql.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2021-03-31T03:39:24.000Z","updated_at":"2025-04-28T00:49:26.000Z","dependencies_parsed_at":"2023-02-17T17:45:39.928Z","dependency_job_id":"c34f6e79-7dcc-46de-b440-e77ea69cfb8d","html_url":"https://github.com/apollographql/supergraph-demo","commit_stats":{"total_commits":463,"total_committers":11,"mean_commits":42.09090909090909,"dds":0.6069114470842333,"last_synced_commit":"03ee2a4dbd264e3ccb159ab5ad5d7a74e3223d05"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apollographql%2Fsupergraph-demo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apollographql%2Fsupergraph-demo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apollographql%2Fsupergraph-demo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apollographql%2Fsupergraph-demo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/apollographql","download_url":"https://codeload.github.com/apollographql/supergraph-demo/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252965091,"owners_count":21832820,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["apollo","apollo-federation","cloud-native","composition","federated-graph","federation","gateway","gitops","graph-router","graphql","kubernetes","schema","schema-checks","subgraph","supergraph"],"created_at":"2024-08-03T01:03:27.618Z","updated_at":"2026-05-28T01:07:33.935Z","avatar_url":"https://github.com/apollographql.png","language":"Shell","funding_links":[],"categories":["Shell"],"sub_categories":[],"readme":"# Supergraph Demo\n\n![smoke test](https://github.com/apollographql/supergraph-demo/actions/workflows/main.yml/badge.svg)\n[![Renovate](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovatebot.com)\n\n\u003e 📣 [Apollo Federation 2 is generally available](https://www.apollographql.com/blog/announcement/backend/apollo-federation-2-is-now-generally-available/)!\nView the [Federation 2 demo](https://github.com/apollographql/supergraph-demo-fed2/blob/main/README.md)!\n\nMoving from dynamic composition to static composition with supergraphs.\n\nContents:\n\n* [Welcome](#welcome)\n* [Prerequisites](#prerequisites)\n* [Local Development](#local-development)\n  * [Local Supergraph Composition](#local-supergraph-composition)\n  * [Apollo Sandbox for Local Development](#apollo-sandbox-for-local-development)\n  * [Tracing with Open Telemetry](#tracing-with-open-telemetry)\n* [Apollo Studio](#apollo-studio)\n  * [Composition in Apollo Studio](#composition-in-apollo-studio)\n  * [Ship Faster Without Breaking Changes](#ship-faster-without-breaking-changes)\n\n* [Standard CI/CD](#standard-cicd)\n  * [Subgraph CI](#subgraph-ci)\n  * [Subgraph Deployment](#subgraph-deployment)\n  * [Gateway CI](#gateway-ci)\n  * [Gateway Deployment](#gateway-deployment)\n* [Deployment Examples](#deployment-examples)\n  * [Kubernetes with Supergraph ConfigMap](#kubernetes-with-supergraph-configmap)\n  * [Serverless](#serverless)\n* [Apollo Router](#apollo-router)\n* [Learn More](#learn-more)\n\nSee also:\n- [apollographql/supergraph-demo-fed2](https://github.com/apollographql/supergraph-demo-fed2/blob/main/README.md)\n- [apollographql/supergraph-demo-k8s-graph-ops](https://github.com/apollographql/supergraph-demo-k8s-graph-ops)\n\n## Welcome\n\n[Apollo Federation](https://www.apollographql.com/docs/federation/) and [Managed Federation](https://www.apollographql.com/docs/federation/managed-federation/overview/) have delivered significant\nimprovements over schema stitching and alternate approaches. Static\ncomposition introduces another big step forward as we move composition out of\nthe Gateway and into the CI pipeline where federated graph changes can be\nvalidated sooner and built into static artifacts that define how a Gateway\nshould route requests across the subgraphs in a federation.\n\nMost contemporary federated GraphQL implementations dynamically compose a\nlist of implementing services (subgraphs) into a GraphQL Gateway at runtime.\nThere is no static artifact that can be versioned, validated, or reasoned\nabout across a fleet of Gateway instances that are common in scale-out\nfederated graph deployments. Gateways often rely on hard-coded behavior for\ndirectives like `join` or accept additional non-GraphQL configuration.\n\nWith static composition, you can compose subgraphs into a supergraph at\nbuild-time resulting in a static artifact (supergraph schema) that describes\nthe machinery to power a graph router at runtime. The supergraph schema\nincludes directives like `join` that instruct a graph router how federate\nmultiple subgraphs into a single graph for consumers to use.\n\n![Apollo Federation with Supergraphs](docs/media/supergraph.png)\n\nSee also: [New Federation UX - Docs](https://www.apollographql.com/docs/federation/quickstart/)\n\n## Prerequisites\n\nYou'll need:\n\n* [docker](https://docs.docker.com/get-docker/)\n* [docker-compose](https://docs.docker.com/compose/install/)\n* `rover` [our new CLI](https://www.apollographql.com/docs/rover/getting-started)\n\nTo install `rover`:\n\n```sh\ncurl -sSL https://rover.apollo.dev/nix/latest | sh\n```\n\n## Local Development\n\n### Local Supergraph Composition\n\nSee also: [Apollo Federation docs](https://www.apollographql.com/docs/federation/quickstart/)\n\nYou can federate multiple subgraphs into a supergraph using:\n\n```sh\nmake demo\n```\n\nwhich does the following:\n\n```sh\n# build a supergraph from 3 subgraphs: products, users, inventory\nmake supergraph\n```\n\nwhich runs:\n\n```\nrover supergraph compose --config ./supergraph.yaml \u003e supergraph.graphql\n```\n\nand then runs:\n\n```\ndocker-compose up -d\n\nCreating apollo-gateway ... done\nCreating inventory ... done\nCreating users     ... done\nCreating products  ... done\n\nStarting Apollo Gateway in local mode ...\nUsing local: supergraph.graphql\n🚀 Graph Router ready at http://localhost:4000/\n```\n\n`make demo` then issues a curl request to the graph router via:\n\n```sh\nmake query\n```\n\nwhich issues the following query that fetches across 3 subgraphs:\n\n```ts\nquery Query {\n  allProducts {\n    id\n    sku\n    createdBy {\n      email\n      totalProductsCreated\n    }\n  }\n}\n```\n\nwith results like:\n\n```ts\n{\n  data: {\n    allProducts: [\n      {\n        id: \"apollo-federation\",\n        sku: \"federation\",\n        createdBy: {\n          email: \"support@apollographql.com\",\n          totalProductsCreated: 1337\n        }\n      },{\n        id: \"apollo-studio\",\n        sku: \"studio\",\n        createdBy:{\n          email: \"support@apollographql.com\",\n          totalProductsCreated: 1337\n        }\n      }\n    ]\n  }\n}\n```\n\n`make demo` then shuts down the graph router:\n\n```\ndocker-compose down\n```\n\n### Apollo Sandbox for Local Development\n\n#### Deploy Graph\n\n```\nmake docker-up\n```\n\n#### Query using Apollo Sandbox\n\n1. Open [http://localhost:4000/](http://localhost:4000/)\n2. Click `Query your server`\n3. Run a query:\n\n```ts\nquery Query {\n  allProducts {\n    id\n    sku\n    createdBy {\n      email\n      totalProductsCreated\n    }\n  }\n}\n```\n\nView results:\n\n![Apollo Sandbox Screenshot](docs/media/apollo-sandbox.png)\n\n#### Cleanup\n\n```\nmake docker-down\n```\n\n### Tracing with Open Telemetry\n\n#### Deploy Graph with Open Telemetry Collector\n\n```\nmake docker-up-otel-collector\n```\n\n#### Run Queries\n\n```\nmake smoke\n```\n\n#### View Open Telemetry Traces\n\nbrowse to [http://localhost:9411/](http://localhost:9411/)\n\n![opentelemetry](docs/media/opentelemetry.png)\n\n#### Cleanup\n\n```\nmake docker-down-otel-collector\n```\n\n#### Send Open Telemetry Traces to Honeycomb\n\nYou can send Open Telemetry from the Gateway to Honeycomb with the following [collector-config.yml](opentelemetry/collector-config.yml):\n\n```\nreceivers:\n  otlp:\n    protocols:\n      grpc:\n      http:\n        cors_allowed_origins:\n          - http://*\n          - https://*\n\nexporters:\n  otlp:\n    endpoint: \"api.honeycomb.io:443\"\n    headers:\n      \"x-honeycomb-team\": \"your-api-key\"\n      \"x-honeycomb-dataset\": \"your-dataset-name\"\n\nservice:\n  pipelines:\n    traces:\n      receivers: [otlp]\n      exporters: [otlp]\n```\n\n![honeycomb](docs/media/honeycomb.png)\n\n#### Learn More\n\n* Docs: [Open Telemetry for Apollo Federation](https://www.apollographql.com/docs/federation/opentelemetry/)\n* Docker compose file: [docker-compose.otel-collector.yml](docker-compose.otel-collector.yml)\n* Helper library: [supergraph-demo-opentelemetry](https://github.com/prasek/supergraph-demo-opentelemetry)\n  * See usage in:\n    * [gateway/gateway.js](gateway/gateway.js)\n    * [subgraphs/products/products.js](subgraphs/products/products.js)\n\n## Apollo Studio\n\n### Composition in Apollo Studio\n\nSee also: [Apollo Studio docs](https://www.apollographql.com/docs/federation/quickstart-pt-2/)\n\n[Managed Federation](https://www.apollographql.com/docs/federation/managed-federation/overview/) in Apollo Studio enables teams to independently publish subgraphs to the Apollo Registry, so they can be automatically composed into a supergraph for apps to use.\n\n#### Create a Federated Graph in Apollo Studio\n\nTo get started with Managed Federation, create your Apollo account:\n\n* Signup for a free Team trial: https://studio.apollographql.com/signup\n* Create an organization\n* **Important:** use the `Team` trial which gives you access Apollo features like `Schema Checks`.\n\nThen create a `Graph` of type `Deployed` with the `Federation` option.\n\nOnce you have created your graph in Apollo Studio, run the following:\n\n```sh\nmake demo-managed\n```\n\n#### Connect to your Graph in Apollo Studio\n\nwhich will prompt for your `graph key` and `graph ref` and save them to `./graph-api.env`:\n\n* `graph key` - the graph API key used to authenticate with Apollo Studio.\n* `graph ref` - a reference to the graph in Apollo's registry the graph router should pull from.\n  * in the form `\u003cgraph-id\u003e@\u003cvariant\u003e`\n  * `@\u003cvariant\u003e` is optional and will default to `@current`\n  * examples: `my-graph@dev`, `my-graph@stage`, `my-graph@prod`\n* see [configuration reference](https://www.apollographql.com/docs/apollo-server/api/apollo-server/#apollo) for details.\n\nNote: The generated `./graph-api.env` holds your `APOLLO_KEY` and `APOLLO_GRAPH_REF`.\n\n#### Publish Subgraph Schemas to the Apollo Registry\n\n`make demo-managed` will publish the `subgraphs/**.graphql` schemas to your new `Federated` graph in the Apollo Registry, which performs managed composition and schema checks, to prevent breaking changes:\n\n```sh\nmake publish\n```\n\nTemporary composition errors may surface as each subgraph is published:\n\n```\n+ rover subgraph publish supergraph-router@dev --routing-url http://products:4000/graphql --schema subgraphs/products/products.graphql --name products\n\nPublishing SDL to supergraph-router:dev (subgraph: products) using credentials from the default profile.\n\nA new subgraph called 'products' for the 'supergraph-router' graph was created.\n\nThe gateway for the 'supergraph-router' graph was NOT updated with a new schema\n\nWARN: The following composition errors occurred:\nUnknown type \"User\".\n[products] Query -\u003e `Query` is an extension type, but `Query` is not defined in any service\n```\n\nSuccess! Once all subgraphs are published the supergraph will be updated, for example:\n\n```\n+ rover subgraph publish supergraph-router@dev --routing-url https://users:4000/graphql --schema subgraphs/users/users.graphql --name users\n\nPublishing SDL to supergraph-router:dev (subgraph: users) using credentials from the default profile.\n\nA new subgraph called 'users' for the 'supergraph-router' graph was created\n\nThe gateway for the 'supergraph-router' graph was updated with a new schema, composed from the updated 'users' subgraph\n```\n\nViewing the `Federated` graph in Apollo Studio we can see the supergraph and the subgraphs it's composed from:\n![Federated Graph in Apollo Studio](docs/media/studio.png)\n\n#### Run the Graph Router and Subgraph Containers\n\nThe graph router and subgraph services will be started by `make demo-managed` next.\n\nusing `docker-compose.managed.yml`:\n\n```yaml\nversion: '3'\nservices:\n  apollo-gateway:\n    container_name: apollo-gateway\n    build: ./gateway\n    environment:\n      - APOLLO_SCHEMA_CONFIG_DELIVERY_ENDPOINT=https://uplink.api.apollographql.com/\n    env_file: # created with: make graph-api-env\n      - graph-api.env\n    ports:\n      - \"4000:4000\"\n  products:\n    container_name: products\n    build: ./subgraphs/products\n  inventory:\n    container_name: inventory\n    build: ./subgraphs/inventory\n  users:\n    container_name: users\n    build: ./subgraphs/users\n```\n\n```sh\nmake docker-up-managed\n```\n\nwhich shows:\n\n```\ndocker-compose -f docker-compose.managed.yml up -d\nCreating network \"supergraph-demo_default\" with the default driver\nCreating apollo-gateway ... done\n\nStarting Apollo Gateway in managed mode ...\nApollo usage reporting starting! See your graph at https://studio.apollographql.com/graph/supergraph-router@dev/\n🚀 Server ready at http://localhost:4000/\n```\n\n#### Make a Federated Query\n\n`make demo-managed` then issues a curl request to the graph router:\n\n```sh\nmake query\n```\n\nwhich has the same query and response as above.\n\n#### Clean Up\n\n`make demo-managed` then shuts down the graph router:\n\n```sh\nmake docker-down\n```\n\n### Ship Faster Without Breaking Changes\n\nSee also: [working with subgraphs docs](https://www.apollographql.com/docs/federation/quickstart-pt-3/)\n\nApollo Schema Checks help ensure subgraph changes don't break the federated graph, reducing downtime and enabling teams to ship faster.\n\n#### The Graph Router will Update In Place\n\nWith Managed Federation you can leave the graph router running and it will\nupdate automatically when subgraph changes are published and they successfully\ncompose and pass all schema checks in Apollo Studio:\n\n```sh\nmake docker-up-managed\n```\n\n```\nStarting Apollo Gateway in managed mode ...\nApollo usage reporting starting! See your graph at https://studio.apollographql.com/graph/supergraph-router@dev/\n🚀 Server ready at http://localhost:4000/\n```\n\n#### Simulating a Change to the Product Subgraph\n\nTo simulate a change to the products subgraph, add a `Color` `enum` to `.subgraphs/products.graphql`:\n\n```ts\nenum Color {\n  BLUE\n  GREEN\n}\n```\n\nThen `publish` the changes to the registry:\n\n```sh\nmake publish\n```\n\nThen remove the `Color` `enum` from `.subgraphs/products.graphql`:\n\n```ts\nenum Color {\n  BLUE\n  GREEN\n}\n```\n\n#### Run a Schema Check\n\nRun a schema `check` against the published version in the registry:\n\n```sh\nmake check-products\n```\n\nThis detects the schema changes and compares them against the known graph `operations` to determine that even though there are schema changes, there is no impact to actual operations so changes can be safely published:\n\n```sh\nChecked the proposed subgraph against supergraph-demo@current\nCompared 3 schema changes against 2 operations\n┌────────┬─────────────────────────┬──────────────────────────────────────────┐\n│ Change │          Code           │               Description                │\n├────────┼─────────────────────────┼──────────────────────────────────────────┤\n│ PASS   │ TYPE_REMOVED            │ type `Color`: removed                    │\n├────────┼─────────────────────────┼──────────────────────────────────────────┤\n│ PASS   │ VALUE_REMOVED_FROM_ENUM │ enum type `Color`: value `BLUE` removed  │\n├────────┼─────────────────────────┼──────────────────────────────────────────┤\n│ PASS   │ VALUE_REMOVED_FROM_ENUM │ enum type `Color`: value `GREEN` removed │\n└────────┴─────────────────────────┴──────────────────────────────────────────┘\n```\n\n#### Publish Validated Subgraph Schemas to Apollo Registry\n\nThen `publish` the changes and `check` again:\n\n```sh\nmake publish\n\nmake check-products\n```\n\nwhich shows:\n\n```\nChecked the proposed subgraph against supergraph-demo@current\nThere were no changes detected in the composed schema.\n```\n\n#### Recap\n\nUsing `rover` in a local dev environment helps catch potentially breaking changes sooner. The next section covers how `rover` can be integrated into your CI/CD environments, and how Managed Federation catches breaking changes before they are delivered to the graph router.\n\n## Standard CI/CD\n\nThis example repo is a monorepo, but this same basic CI/CD workflow applies for single-repo-per-package scenarios.\n\n### Subgraph CI\n\n* Create [graph variants](https://www.apollographql.com/docs/studio/org/graphs/) in Apollo Studio for `dev`, `staging`, and `prod`:\n* Configure [schema checks](https://www.apollographql.com/docs/studio/schema-checks/) for your graph:\n  * [Federated composition checks](https://www.apollographql.com/docs/studio/schema-checks/#federated-composition-checks) will run against the subgraph schemas published to each variant.\n  * [Operation checks](https://www.apollographql.com/docs/studio/schema-checks/#types-of-checks) should be configured to validate real world [schema usage](https://www.apollographql.com/docs/studio/check-configurations/#using-apollo-studio-recommended) with usage data from `staging` and `prod` variants.\n  * Configure Gateway deployments to provide [usage reporting](https://www.apollographql.com/docs/apollo-server/api/plugin/usage-reporting/#gatsby-focus-wrapper) data for operation checks.\n  * CI for each subgraph for source pull requests: [subgraph-check.yml](https://github.com/apollographql/supergraph-demo/blob/main/.github/workflows/subgraph-check.yml)\n    * `rover subgraph check`\n    * schema checks against schema in the `dev` variant\n    * operation checks against usage data in the `prod` and typically `stage` variants.\n\n* If you’re in a monorepo:\n  * Consider using 3-way merges and [overriding the APOLLO_VCS_COMMIT and/or APOLLO_VCS_BRANCH](https://www.apollographql.com/docs/rover/configuring/#overriding) to correlate schema changes for subgraph changes.\n\nWith this approach, failed schema checks ([example](https://github.com/apollographql/supergraph-demo/pull/32)) are caught as close to the source of\nthe change as possible, but only fully validated supergraph schemas are\npublished for use.\n\n![schema-check-breaking-change](docs/media/ci/schema-check-breaking-change.png)\n\nBreaking changes are sometimes intentional, and to accommodate this, Apollo\nStudio has the option to mark certain changes as safe in the UI, that provides a\ncheck report URL in your CI, so you can easily navigate to Apollo Studio to:\nreview the check, mark things safe and then re-run your pipeline.\n\n![schema-check-mark-safe](docs/media/schema-check-mark-safe.png)\n\n### Subgraph Deployment\n\n* Run a deployment workflow like this simple example [subgraph-deploy-publish.yml](https://github.com/apollographql/supergraph-demo/blob/main/.github/workflows/subgraph-deploy-publish.yml)\n  * Before subgraph deployment\n    * Do a reality check with `rover subgraph check`\n  * Deploy subgraph service\n    * Should have the service deployed before publishing the subgraph schema\n  * After subgraph deployment\n    * Publish the subgraph schema to the registry with `rover subgraph publish`\n    * Managed Federation will run central schema checks and operation check and  publish a new supergraph schema for the Gateways in the fleet for each environment\n\nPublishing subgraph schema changes with `rover subgraph publish` always stores a new subgraph schema version to the Apollo Registry, even if schema checks don’t pass.\n\n[Managed Federation](https://www.apollographql.com/docs/federation/managed-federation/overview/) ultimately catches all breaking changes prior before a new supergraph schema is published:\n\n* Runs schema checks after each `rover subgraph publish`\n* Composes a supergraph schema if all checks pass\n* Makes the supergraph schema available in the:\n  * `Apollo Uplink` - that the Gateway can poll for live updates (default).\n  * `Apollo Registry` - for retrieval via `rover supergraph fetch`.\n  * `Apollo Supergraph Build Webhook` - for custom integrations\n\nKey benefits to Managed Federation:\n\n* CI for multiple concurrent `rover subgraph publish` from multiple service repos\n* Central point of control \u0026 governance\n* Globally consistent schema checks and composition\n* Catches breaking changes at supergraph build time before a new supergraph is published, before they're published for Gateways to use.\n\n### Gateway CI\n\nThe Gateway image and configuration can be managed using standard CI practices.\n\nFor example, if using Docker images:\n\n* see [example monorepo release workflow](https://github.com/apollographql/supergraph-demo/blob/main/.github/workflows/release.yml)\n* bumps package versions in this `source repo`\n* build \u0026 push Gateway docker images to DockerHub\n\n### Gateway Deployment\n\nThe default configuration for the Gateway is to update in place by pulling new supergraph schema versions as they're published to the Apollo Uplink. Gateways in the fleet poll the Uplink every 10 seconds by default, so there will be a fast rolling upgrade as Gateways check the Uplink, without the need to restart the Gateway.\n\nUpdate in place is useful for any long-lived Gateway instance where an immediate update of the Gateway instance's supergraph schema is desired. \n\nUpdate-in-place with Managed Federation is useful for:\n* long-lived VMs\n* Kubernetes `Deployments`\n* Serverless functions that may be cached outside of operator control.\n\n[Configure the Gateways in each fleet](https://www.apollographql.com/docs/federation/managed-federation/setup/#3-modify-the-gateway-if-necessary) `dev`, `staging`, `prod` to:\n\n* pull supergraph schema from their respective graph variants, via the [Apollo Uplink](https://www.apollographql.com/docs/federation/quickstart-pt-2/#managed-federation-basics).\n* provide [usage reporting](https://www.apollographql.com/docs/apollo-server/api/plugin/usage-reporting/#gatsby-focus-wrapper) data for operation checks.\n\n### Custom Gateway Deployments\n\nYou can do custom CD with the following hooks and the `rover` CLI:\n\n* [supergraph build webhook](https://www.apollographql.com/blog/announcement/webhooks/) - pushes from Managed Federation.\n* `rover supergraph fetch` - pulls from the `Apollo Registry`.\n\nSee [Kubernetes-native GraphOps](https://github.com/apollographql/supergraph-demo-k8s-graph-ops) to learn more about using custom CD with Kubernetes and GitOps.\n\n## Deployment Examples\n\n### Kubernetes with Supergraph ConfigMap\n\nYou'll need the latest versions of:\n\n* [kubectl](https://kubernetes.io/docs/tasks/tools/) - with expanded `kustomize` support for `resources`\n* [kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)\n\nthen run:\n\n```sh\nmake demo-k8s\n```\n\nwhich generates a graph router `Deployment` and supergraph `ConfigMap` using:\n\n```\nkubectl kustomize k8s/router/base\n```\n\nand then creates:\n\n* local k8s cluster with the NGINX Ingress Controller\n* graph-router `Deployment` configured to use a supergraph `ConfigMap`\n* graph-router `Service` and `Ingress`\n\n### Gateway Deployment with Supergraph ConfigMap\n\nusing [k8s/router/base/router.yaml](k8s/router/base/router.yaml) via:\n\n```sh\nkubectl apply -k k8s/router/base\n```\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  labels:\n    app: router\n  name: router-deployment\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: router\n  template:\n    metadata:\n      labels:\n        app: router\n    spec:\n      containers:\n      - env:\n        - name: APOLLO_SCHEMA_CONFIG_EMBEDDED\n          value: \"true\"\n        image: prasek/supergraph-router:latest\n        name: router\n        ports:\n        - containerPort: 4000\n        volumeMounts:\n        - mountPath: /etc/config\n          name: supergraph-volume\n      volumes:\n      - configMap:\n          name: supergraph-c22698b7b9\n        name: supergraph-volume\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: supergraph-c22698b7b9\ndata:\n  supergraph.graphql: |\n    schema\n      @core(feature: \"https://specs.apollo.dev/core/v0.1\"),\n      @core(feature: \"https://specs.apollo.dev/join/v0.1\")\n    {\n      query: Query\n    }\n\n    ...\n\n    enum join__Graph {\n      INVENTORY @join__graph(name: \"inventory\" url: \"http://inventory:4000/graphql\")\n      PRODUCTS @join__graph(name: \"products\" url: \"http://products:4000/graphql\")\n      USERS @join__graph(name: \"users\" url: \"https://users:4000/graphql\")\n    }\n\n    type Product\n      @join__owner(graph: PRODUCTS)\n      @join__type(graph: PRODUCTS, key: \"id\")\n      @join__type(graph: PRODUCTS, key: \"sku package\")\n      @join__type(graph: PRODUCTS, key: \"sku variation{id}\")\n      @join__type(graph: INVENTORY, key: \"id\")\n    {\n      id: ID! @join__field(graph: PRODUCTS)\n      sku: String @join__field(graph: PRODUCTS)\n      package: String @join__field(graph: PRODUCTS)\n      variation: ProductVariation @join__field(graph: PRODUCTS)\n      dimensions: ProductDimension @join__field(graph: PRODUCTS)\n      createdBy: User @join__field(graph: PRODUCTS, provides: \"totalProductsCreated\")\n      delivery(zip: String): DeliveryEstimates @join__field(graph: INVENTORY, requires: \"dimensions{size weight}\")\n    }\n\n    type ProductDimension {\n      size: String\n      weight: Float\n    }\n\n    type ProductVariation {\n      id: ID!\n    }\n\n    type Query {\n      allProducts: [Product] @join__field(graph: PRODUCTS)\n      product(id: ID!): Product @join__field(graph: PRODUCTS)\n    }\n\n    type User\n      @join__owner(graph: USERS)\n      @join__type(graph: USERS, key: \"email\")\n      @join__type(graph: PRODUCTS, key: \"email\")\n    {\n      email: ID! @join__field(graph: USERS)\n      name: String @join__field(graph: USERS)\n      totalProductsCreated: Int @join__field(graph: USERS)\n    }\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: router-service\nspec:\n  ports:\n  - port: 4000\n    protocol: TCP\n    targetPort: 4000\n  selector:\n    app: router\n---\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n  annotations:\n    kubernetes.io/ingress.class: nginx\n  name: router-ingress\nspec:\n  rules:\n  - http:\n      paths:\n      - backend:\n          service:\n            name: router-service\n            port:\n              number: 4000\n        path: /\n        pathType: Prefix\n```\n\nand 3 subgraph services [k8s/subgraphs/base/subgraphs.yaml](k8s/subgraphs/base/subgraphs.yaml) via:\n\n```sh\nkubectl kustomize k8s/subgraphs/base\n```\n\n### Make a GraphQL Query\n\n`make demo-k8s` then runs the following in a loop until the query succeeds or 2 min timeout:\n\n```sh\nkubectl get all\nmake k8s-query\n```\n\nwhich shows the following:\n\n```\nNAME                                     READY   STATUS    RESTARTS   AGE\npod/inventory-65494cbf8f-bhtft           1/1     Running   0          59s\npod/products-6d75ff449c-9sdnd            1/1     Running   0          59s\npod/router-deployment-84cbc9f689-8fcnf   1/1     Running   0          20s\npod/users-d85ccf5d9-cgn4k                1/1     Running   0          59s\n\nNAME                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE\nservice/inventory        ClusterIP   10.96.108.120   \u003cnone\u003e        4000/TCP   59s\nservice/kubernetes       ClusterIP   10.96.0.1       \u003cnone\u003e        443/TCP    96s\nservice/products         ClusterIP   10.96.65.206    \u003cnone\u003e        4000/TCP   59s\nservice/router-service   ClusterIP   10.96.178.206   \u003cnone\u003e        4000/TCP   20s\nservice/users            ClusterIP   10.96.98.53     \u003cnone\u003e        4000/TCP   59s\n\nNAME                                READY   UP-TO-DATE   AVAILABLE   AGE\ndeployment.apps/inventory           1/1     1            1           59s\ndeployment.apps/products            1/1     1            1           59s\ndeployment.apps/router-deployment   1/1     1            1           20s\ndeployment.apps/users               1/1     1            1           59s\n\nNAME                                           DESIRED   CURRENT   READY   AGE\nreplicaset.apps/inventory-65494cbf8f           1         1         1       59s\nreplicaset.apps/products-6d75ff449c            1         1         1       59s\nreplicaset.apps/router-deployment-84cbc9f689   1         1         1       20s\nreplicaset.apps/users-d85ccf5d9                1         1         1       59s\nSmoke test\n-------------------------------------------------------------------------------------------\n++ curl -X POST -H 'Content-Type: application/json' --data '{ \"query\": \"{ allProducts { id, sku, createdBy { email, totalProductsCreated } } }\" }' http://localhost:80/\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n100   352  100   267  100    85   3000    955 --:--:-- --:--:-- --:--:--  3911\n{\"data\":{\"allProducts\":[{\"id\":\"apollo-federation\",\"sku\":\"federation\",\"createdBy\":{\"email\":\"support@apollographql.com\",\"totalProductsCreated\":1337}},{\"id\":\"apollo-studio\",\"sku\":\"studio\",\"createdBy\":{\"email\":\"support@apollographql.com\",\"totalProductsCreated\":1337}}]}}\nSuccess!\n-------------------------------------------------------------------------------------------\n```\n\n### Cleanup\n\n`make demo-k8s` then cleans up:\n\n```\ndeployment.apps \"graph-router\" deleted\nservice \"graphql-service\" deleted\ningress.networking.k8s.io \"graphql-ingress\" deleted\nDeleting cluster \"kind\" ...\n```\n\n## Serverless\n\nSee [serverless.yml](serverless/serverless.yml)\n\n```\nmake demo-serverless\n```\n\nwhich does the following:\n\n```\nrover supergraph compose --config serverless/supergraph.yaml \u003e serverless/supergraph.graphql\ndocker-compose -f docker-compose.serverless.yml up -d\nCreating network \"supergraph-demo_default\" with the default driver\nCreating serverless ... done\ndocker-compose -f docker-compose.serverless.yml logs\nAttaching to serverless\nserverless    | Serverless: Running \"serverless\" installed locally (in service node_modules)\nserverless    | offline: Starting Offline: dev/us-east-1.\nserverless    | offline: Offline [http for lambda] listening on http://0.0.0.0:3002\nserverless    | offline: Function names exposed for local invocation by aws-sdk:\nserverless    |            * router: supergraph-serverless-dev-router\nserverless    |            * inventory: supergraph-serverless-dev-inventory\nserverless    |            * products: supergraph-serverless-dev-products\nserverless    |            * users: supergraph-serverless-dev-users\nserverless    |\nserverless    |  ┌───────────────────────────────────────────────────────────────────────────┐\nserverless    |  │                                                                           │\nserverless    |  │   ANY | http://0.0.0.0:4000/                                              │\nserverless    |  │   POST | http://0.0.0.0:4000/2015-03-31/functions/router/invocations      │\nserverless    |  │   ANY | http://0.0.0.0:4000/inventory                                     │\nserverless    |  │   POST | http://0.0.0.0:4000/2015-03-31/functions/inventory/invocations   │\nserverless    |  │   ANY | http://0.0.0.0:4000/products                                      │\nserverless    |  │   POST | http://0.0.0.0:4000/2015-03-31/functions/products/invocations    │\nserverless    |  │   ANY | http://0.0.0.0:4000/users                                         │\nserverless    |  │   POST | http://0.0.0.0:4000/2015-03-31/functions/users/invocations       │\nserverless    |  │                                                                           │\nserverless    |  └───────────────────────────────────────────────────────────────────────────┘\nserverless    |\nserverless    | offline: [HTTP] server ready: http://0.0.0.0:4000 🚀\nserverless    | offline:\nserverless    | offline: Enter \"rp\" to replay the last request\n-------------------------------------------------------------------------------------------\n++ curl -X POST -H 'Content-Type: application/json' --data '{ \"query\": \"{allProducts{id,sku,createdBy{email,totalProductsCreated}}}\" }' http://localhost:4000/\n  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\n                                 Dload  Upload   Total   Spent    Left  Speed\n100   341  100   267  100    74    331     91 --:--:-- --:--:-- --:--:--   423\n\nResult:\n{\"data\":{\"allProducts\":[{\"id\":\"apollo-federation\",\"sku\":\"federation\",\"createdBy\":{\"email\":\"support@apollographql.com\",\"totalProductsCreated\":1337}},{\"id\":\"apollo-studio\",\"sku\":\"studio\",\"createdBy\":{\"email\":\"support@apollographql.com\",\"totalProductsCreated\":1337}}]}}\n-------------------------------------------------------------------------------------------\ndocker-compose -f docker-compose.serverless.yml down\nStopping serverless ... done\nRemoving serverless ... done\nRemoving network supergraph-demo_default\n```\n\n## Apollo Router\n\n[The Apollo Router](https://www.apollographql.com/blog/announcement/backend/apollo-router-our-graphql-federation-runtime-in-rust) is our next-generation GraphQL Federation runtime written in Rust, and it is fast.\n\nAs a Graph Router, the Apollo Router plays the same role as the Apollo Gateway. The same subgraph schemas and composed supergraph schema can be used in both the Router and the Gateway.\n\nThis demo shows using the Apollo Router with a Federation 1 supergraph schema, composed using the Fed 1 `rover supergraph compose` command. To see the Router working with Federation 2 composition, checkout the Apollo Router section of [apollographql/supergraph-demo-fed2](https://github.com/apollographql/supergraph-demo-fed2/blob/main/README.md#apollo-router).\n\n[Early benchmarks](https://www.apollographql.com/blog/announcement/backend/apollo-router-our-graphql-federation-runtime-in-rust) show that the Router adds less than 10ms of latency to each operation, and it can process 8x the load of the JavaScript Apollo Gateway.\n\nTo get started with the Router:\n\n```\nmake demo-local-router\n```\n\nthis uses a simple [docker-compose.router.yml](docker-compose.router.yml) file:\n```yaml\nversion: '3'\nservices:\n  apollo-router:\n    container_name: apollo-router\n    build: ./router\n    volumes:\n      - ./supergraph.graphql:/etc/config/supergraph.graphql\n      - ./router/configuration.yaml:/etc/config/configuration.yaml\n    ports:\n      - \"4000:4000\"\n  products:\n    container_name: products\n    build: ./subgraphs/products\n  inventory:\n    container_name: inventory\n    build: ./subgraphs/inventory\n  users:\n    container_name: users\n    build: ./subgraphs/users\n```\n\nwhich uses the following [Dockerfile](router/Dockerfile)\n```\nfrom ubuntu\n\nWORKDIR /usr/src/app\nRUN apt-get update \u0026\u0026 apt-get install -y \\\n    libssl-dev \\\n    curl \\\n    jq\n\nCOPY install.sh .\nCOPY run.sh .\nRUN ./install.sh\n\nCMD [ \"/usr/src/app/run.sh\" ]\n```\n\nsee [./router](router) for more details.\n\n## Learn More\n\nApollo tools and services help you develop, maintain, operate, and scale your data graph.\n\n* [Shipping faster with managed federation and schema checks](https://www.apollographql.com/docs/studio/)\n\n* [Kubernetes-native GraphOps](https://github.com/apollographql/supergraph-demo-k8s-graph-ops) \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fapollographql%2Fsupergraph-demo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fapollographql%2Fsupergraph-demo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fapollographql%2Fsupergraph-demo/lists"}