Schedule icon
Request icon
Script icon
Process icon
If icon
SlackIncomingWebhook icon
Fail icon
Log icon

GraphQL schema breaking change preflight gate

Audit GraphQL schema changes between staging and production via introspection, detect breaking field deletions, and alert teams to prevent API client failures.

Categories
CloudInfrastructure

Prevent breaking API changes and client application outages by automatically verifying backward compatibility before deploying GraphQL services to production. In agile development teams, engineers frequently delete fields, rename object types, or alter schema contracts during feature refactors without realizing active mobile applications and partner integrations depend on the old schema. This blueprint queries both staging and production GraphQL endpoints via introspection (io.kestra.plugin.graphql.Request), isolates removed types and deleted fields using a Python comparison task, notifies engineering teams via Slack with an itemized diff, and terminates with a pipeline failure to gate downstream CI/CD deployment jobs.

How it works

  1. A Schedule trigger initiates a preflight verification sweep every weekday morning at 06:00 UTC (shipped disabled by default).
  2. Task fetch_production_schema and task fetch_staging_schema query the live production and candidate staging GraphQL endpoints using io.kestra.plugin.graphql.Request to introspect __schema { types { name kind fields { name args { name } } } }.
  3. Task detect_schema_breaking_changes (io.kestra.plugin.scripts.python.Script) parses both schema payloads, filters out internal introspection types (__Schema, __Type), maps type fields, and flags any fields or types present in production that have been deleted in staging.
  4. Task evaluate_breaking_contract (io.kestra.plugin.core.flow.If) evaluates the breaking change count:
    • If breaking changes are found: Task alert_breaking_changes posts an itemized Slack alert listing every deleted field and type. If fail_on_breaking_changes is enabled, task halt_deployment_gate fails the execution to prevent production deployment.
    • If backward-compatible: Task log_contract_compatible records that the staging schema is clean.
  5. Task log_preflight_summary logs the audit summary.
  6. Top-level errors handler alerts API Platform engineering if introspection endpoints fail or tokens expire.

What you get

  • Automated detection of deleted fields and removed types before code ships to production.
  • Protection against broken mobile and web client releases relying on existing GraphQL contracts.
  • Actionable Slack notifications directing backend developers to use @deprecated directives instead of hard removals.
  • A reliable CI/CD gate that can be invoked via webhooks or schedules to block non-compliant deployments.

Who it's for

  • API Platform and Governance teams overseeing microservice subgraphs and federated supergraphs.
  • DevOps and CI/CD engineers configuring automated release gates in GitLab, GitHub Actions, or ArgoCD.
  • Frontend and Mobile Leads protecting existing application versions against backend schema regressions.

Why orchestrate this with Kestra

Standalone schema registry tools often charge heavy per-seat SaaS fees or require complex CLI integrations in every microservice repo. Kestra provides an orchestrator-native, declarative schema comparison gate. With native GraphQL introspection tasks, isolated Python script evaluation, secure secret handling for staging/prod tokens, and rich Slack alerting, Kestra acts as a central governance control plane across all your API services.

Prerequisites

  • Accessible staging and production GraphQL endpoints supporting introspection queries.
  • API tokens or secrets if endpoints require authorization.
  • A Slack Incoming Webhook URL.

Secrets

  • GRAPHQL_PROD_TOKEN: Production API access token passed in the Authorization: Bearer header.
  • GRAPHQL_STAGING_TOKEN: Staging API access token passed in the Authorization: Bearer header.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to transmit breaking change alerts.

Quick start

  1. Store your staging/production tokens and Slack webhook in Kestra Secrets (GRAPHQL_PROD_TOKEN, GRAPHQL_STAGING_TOKEN, and SLACK_WEBHOOK_URL).
  2. Set staging_graphql_url and production_graphql_url inputs to your service URLs.
  3. Run a manual execution in Kestra to verify that both schemas introspect cleanly.
  4. Enable the pre_deployment_audit_schedule trigger or integrate the flow into your deployment pipeline via Webhook trigger.

How to extend

  • Extend the Python comparison logic to check for changed argument types, non-null argument additions, and enum value deletions.
  • Post automated review comments on GitHub Pull Requests with the breaking change diff before merging.
  • Store historical schema snapshots in S3 or MinIO to track schema evolution over quarterly release cycles.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.