Allow known `FeatureDefinition` subclasses to define custom subgraph schema validation rules by benjamn · Pull Request #2910 · apollographql/federation

benjamn · 2024-01-16T21:53:14Z

There are a number of // TODO comments left in this implementation, but this PR demonstrates a basic framework for allowing known FeatureDefinition subclasses, like SourceSpecDefinition, to define their own subgraph validation rules, by overriding the validateSubgraphSchema(schema: Schema): GraphQLError[] method.

It's the responsibility of validateSubgraphSchema to determine if its validation rules are applicable to a given schema, ideally returning an empty array quickly if the feature in question is not used in the schema.

In order for validateKnownFeatures to work, a given FeatureDefinition subclass needs to have been registered with registerKnownFeature.

I'll keep working on the TODOs and the tests.

codesandbox-ci · 2024-01-16T21:54:11Z

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

internals-js/src/specs/sourceSpec.ts

package.json

internals-js/src/specs/sourceSpec.ts

clenfest · 2024-01-17T14:30:01Z

internals-js/src/specs/sourceSpec.ts

Is there a reason you're doing this as opposed to const { name, http }?

Just trying to be agnostic to eventually having more than just http in KNOWN_SOURCE_PROTOCOLS.

It's just style, so I'm not going to hold up the release for it, but imo it's a little cleaner to say

const { api, http, grpc, sql } = application.arguments(); if (http) { assert(apiNameToProtocol.get(api) === 'http', ...); } else if (grpc) { assert(apiNameToProtocol.get(api) === 'grpc', ...); ... }

internals-js/src/specs/sourceSpec.ts

…a per directive basis

#2910 (comment)

Analogous to 56a7816.

internals-js/src/error.ts

docs/source/errors.md

#2910 (comment)

@OverRide

This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated. # Releases ## @apollo/composition@2.7.0 ### Minor Changes - Implement progressive `@override` functionality ([#2911](#2911)) The progressive `@override` feature brings a new argument to the `@override` directive: `label: String`. When a label is added to an `@override` application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only. Out-of-the-box, the router will support a percentage-based use case for progressive `@override`. For example: ```graphql type Query { hello: String @OverRide(from: "original", label: "percent(5)") } ``` The above example will override the root `hello` field from the "original" subgraph 5% of the time. More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service). - Support `@join__directive(graphs, name, args)` directives ([#2894](#2894)) ### Patch Changes - Allow known `FeatureDefinition` subclasses to define custom subgraph schema validation rules ([#2910](#2910)) - Updated dependencies \[[`6ae42942b13dccd246ccc994faa2cb36cd62cb3c`](6ae4294), [`66833fb8d04c9376f6ed476fed6b1ca237f477b7`](66833fb), [`931f87c6766c7439936df706727cbdc0cd6bcfd8`](931f87c)]: - @apollo/query-graphs@2.7.0 - @apollo/federation-internals@2.7.0 ## @apollo/gateway@2.7.0 ### Minor Changes - Implement progressive `@override` functionality ([#2911](#2911)) The progressive `@override` feature brings a new argument to the `@override` directive: `label: String`. When a label is added to an `@override` application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only. Out-of-the-box, the router will support a percentage-based use case for progressive `@override`. For example: ```graphql type Query { hello: String @OverRide(from: "original", label: "percent(5)") } ``` The above example will override the root `hello` field from the "original" subgraph 5% of the time. More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service). ### Patch Changes - Updated dependencies \[[`6ae42942b13dccd246ccc994faa2cb36cd62cb3c`](6ae4294), [`66833fb8d04c9376f6ed476fed6b1ca237f477b7`](66833fb), [`931f87c6766c7439936df706727cbdc0cd6bcfd8`](931f87c)]: - @apollo/query-planner@2.7.0 - @apollo/composition@2.7.0 - @apollo/federation-internals@2.7.0 ## @apollo/federation-internals@2.7.0 ### Minor Changes - Implement progressive `@override` functionality ([#2911](#2911)) The progressive `@override` feature brings a new argument to the `@override` directive: `label: String`. When a label is added to an `@override` application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only. Out-of-the-box, the router will support a percentage-based use case for progressive `@override`. For example: ```graphql type Query { hello: String @OverRide(from: "original", label: "percent(5)") } ``` The above example will override the root `hello` field from the "original" subgraph 5% of the time. More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service). - Allow known `FeatureDefinition` subclasses to define custom subgraph schema validation rules ([#2910](#2910)) - Support `@join__directive(graphs, name, args)` directives ([#2894](#2894)) ## @apollo/query-graphs@2.7.0 ### Minor Changes - Implement progressive `@override` functionality ([#2911](#2911)) The progressive `@override` feature brings a new argument to the `@override` directive: `label: String`. When a label is added to an `@override` application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only. Out-of-the-box, the router will support a percentage-based use case for progressive `@override`. For example: ```graphql type Query { hello: String @OverRide(from: "original", label: "percent(5)") } ``` The above example will override the root `hello` field from the "original" subgraph 5% of the time. More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service). ### Patch Changes - Updated dependencies \[[`6ae42942b13dccd246ccc994faa2cb36cd62cb3c`](6ae4294), [`66833fb8d04c9376f6ed476fed6b1ca237f477b7`](66833fb), [`931f87c6766c7439936df706727cbdc0cd6bcfd8`](931f87c)]: - @apollo/federation-internals@2.7.0 ## @apollo/query-planner@2.7.0 ### Minor Changes - Implement progressive `@override` functionality ([#2911](#2911)) The progressive `@override` feature brings a new argument to the `@override` directive: `label: String`. When a label is added to an `@override` application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only. Out-of-the-box, the router will support a percentage-based use case for progressive `@override`. For example: ```graphql type Query { hello: String @OverRide(from: "original", label: "percent(5)") } ``` The above example will override the root `hello` field from the "original" subgraph 5% of the time. More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service). ### Patch Changes - Updated dependencies \[[`6ae42942b13dccd246ccc994faa2cb36cd62cb3c`](6ae4294), [`66833fb8d04c9376f6ed476fed6b1ca237f477b7`](66833fb), [`931f87c6766c7439936df706727cbdc0cd6bcfd8`](931f87c)]: - @apollo/query-graphs@2.7.0 - @apollo/federation-internals@2.7.0 ## @apollo/subgraph@2.7.0 ### Minor Changes - Implement progressive `@override` functionality ([#2911](#2911)) The progressive `@override` feature brings a new argument to the `@override` directive: `label: String`. When a label is added to an `@override` application, the override becomes conditional, depending on parameters provided to the query planner (a set of which labels should be overridden). Note that this feature will be supported in router for enterprise users only. Out-of-the-box, the router will support a percentage-based use case for progressive `@override`. For example: ```graphql type Query { hello: String @OverRide(from: "original", label: "percent(5)") } ``` The above example will override the root `hello` field from the "original" subgraph 5% of the time. More complex use cases will be supported by the router via the use of coprocessors/rhai to resolve arbitrary labels to true/false values (i.e. via a feature flag service). ### Patch Changes - Updated dependencies \[[`6ae42942b13dccd246ccc994faa2cb36cd62cb3c`](6ae4294), [`66833fb8d04c9376f6ed476fed6b1ca237f477b7`](66833fb), [`931f87c6766c7439936df706727cbdc0cd6bcfd8`](931f87c)]: - @apollo/federation-internals@2.7.0 ## apollo-federation-integration-testsuite@2.7.0 Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

Follow-up to PR #2910.

benjamn self-assigned this Jan 16, 2024

This comment was marked as resolved.

Sign in to view

benjamn commented Jan 16, 2024

View reviewed changes

internals-js/src/specs/sourceSpec.ts Outdated Show resolved Hide resolved

clenfest reviewed Jan 17, 2024

View reviewed changes

clenfest and others added 12 commits January 19, 2024 14:50

Ideas for some basic callbacks for allowing for custom validation on …

9c8991c

…a per directive basis

Enable FeatureDefinition schema validation via validateKnownFeatures.

7a8b8bb

Implement easy validation rules, leaving some trickier TODOs.

235dddb

Basic initial validation error tests.

30b7713

Let @source* directives be renamed when imported.

c942d0d

#2910 (comment)

Use HTTP_PROTOCOL constant instead of string literal.

633e787

#2910 (comment)

Use @ more consistently in @source* directive validation errors.

168b83b

Forbid body argument for GET and DELETE requests.

34fb5dc

Decompose separate validation method for each @source* directive.

746fc4d

#2910 (comment)

Add keyTypeMap argument to @sourceField.

ccbdd24

Use assertName from graphql package instead of hard-coded RegExp.

d35bc4e

#2910 (comment)

Establish known error codes for @source* directives.

5ffb16f

#2910 (comment)

benjamn force-pushed the benjamn/validate-@source-directives branch from f9d1d1b to 5ffb16f Compare January 19, 2024 20:01

benjamn added 2 commits January 19, 2024 15:04

Add changeset.

a5f9650

Add new errors to errors.md.

8d6fbd7

#2910 (comment)

benjamn marked this pull request as ready for review January 19, 2024 20:23

benjamn requested review from a team as code owners January 19, 2024 20:23

benjamn requested a review from clenfest January 19, 2024 20:24

benjamn added 2 commits January 19, 2024 15:30

Improve formatting of @source*-related errors.

768b9ca

Use FeatureUrl.maybeParse to avoid throwing.

a84fc2e

Analogous to 56a7816.

clenfest reviewed Jan 19, 2024

View reviewed changes

internals-js/src/error.ts Show resolved Hide resolved

clenfest reviewed Jan 19, 2024

View reviewed changes

docs/source/errors.md Outdated Show resolved Hide resolved

Use addedIn:2.7.0 for new errors.

0736da2

#2910 (comment)

clenfest approved these changes Jan 19, 2024

View reviewed changes

benjamn merged commit 66833fb into next Jan 19, 2024

benjamn deleted the benjamn/validate-@source-directives branch January 19, 2024 21:20

github-actions bot mentioned this pull request Jan 19, 2024

release: on branch next #2878

Merged

github-actions bot mentioned this pull request Jan 20, 2024

release: on branch main #2913

Merged

benjamn mentioned this pull request Jan 23, 2024

Additional SourceSpecDefinition validations #2914

Merged

benjamn added a commit that referenced this pull request Jan 24, 2024

Additional SourceSpecDefinition validations (#2914)

493f5ac

Follow-up to PR #2910.

This was referenced Feb 1, 2024

Allow @sourceField on fields of object types _and_ type extensions. #2925

Open

Improve validation of URLPathTemplate and JSONSelection strings passed to @source{Type,Field} directives #2926

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow known `FeatureDefinition` subclasses to define custom subgraph schema validation rules#2910

Allow known `FeatureDefinition` subclasses to define custom subgraph schema validation rules#2910
benjamn merged 17 commits intonextfrom
benjamn/validate-@source-directives

benjamn commented Jan 16, 2024

Uh oh!

This comment was marked as resolved.

codesandbox-ci bot commented Jan 16, 2024 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

clenfest Jan 17, 2024

Uh oh!

benjamn Jan 19, 2024

Uh oh!

clenfest Jan 19, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

benjamn commented Jan 16, 2024

Uh oh!

This comment was marked as resolved.

codesandbox-ci bot commented Jan 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

clenfest Jan 17, 2024

Choose a reason for hiding this comment

Uh oh!

benjamn Jan 19, 2024

Choose a reason for hiding this comment

Uh oh!

clenfest Jan 19, 2024

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

codesandbox-ci bot commented Jan 16, 2024 •

edited

Loading