Skip to content

feat: add progressive @override support with label argument#314

Open
mcheemaa wants to merge 1 commit into
Gusto:mainfrom
mcheemaa:feat/progressive-override-label
Open

feat: add progressive @override support with label argument#314
mcheemaa wants to merge 1 commit into
Gusto:mainfrom
mcheemaa:feat/progressive-override-label

Conversation

@mcheemaa
Copy link
Copy Markdown

Summary

Adds support for the label argument on the @override directive, enabling progressive/percentage-based traffic splitting during subgraph migrations.

Motivation

Apollo Federation v2.7 introduced progressive @override which allows gradual migration of fields between subgraphs by controlling the percentage of traffic routed to each. This is useful for safely migrating high-traffic fields.

Apollo Documentation: https://www.apollographql.com/blog/safer-migrations-of-fields-using-progressive-rollouts

Usage

class MySchema < GraphQL::Schema
  federation version: '2.7'
end

# Routes 10% of traffic to this subgraph, 90% to 'products'
field :in_stock, Boolean, null: false, override: { from: 'products', label: 'percent(10)' }

Generated SDL:

type Product {
  inStock: Boolean! @federation__override(from: "products", label: "percent(10)")
}

Changes

  • lib/apollo-federation/field.rb - Added optional label argument to @override directive
  • lib/apollo-federation/schema.rb - Made federation version configurable in @link URL (>= 2.3 uses specified version, otherwise defaults to 2.3 for backwards compatibility)
  • spec/apollo-federation/service_field_v2_spec.rb - Added tests for label argument and version configurability
  • README.md - Updated documentation

Backwards Compatibility

  • Existing override: { from: 'X' } usage continues to work unchanged
  • Schemas using federation version: '2.0' still output v2.3 in the @link URL (current behavior)
  • The label argument is optional

@swcollard
Copy link
Copy Markdown

Hello @mcheemaa

Unfortunately we are not actively maintaining this repo or accepting contributions at the time, but are considering getting back to it soon.

Given that apollo-federation-ruby is currently supporting Apollo Federtion v2.3, I'm also hesitant to accept a single feature from v2.7 without bringing support for the whole library up to spec with that version of Apollo Federation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants