diff --git a/.changeset/fresh-kangaroos-exist.md b/.changeset/fresh-kangaroos-exist.md deleted file mode 100644 index a9ae084b8fa..00000000000 --- a/.changeset/fresh-kangaroos-exist.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -"@graphql-tools/stitch": minor ---- - -New option `useNonNullableFieldOnConflict` in `typeMergingOptions` of `stitchSchemas` - -When you have two schemas like below, you will get a warning about the conflicting fields because `name` field is defined as non-null in one schema and nullable in the other schema, and non-nullable field can exist in the stitched schema because of the order or any other reasons, and this might actually cause an unexpected behavior when you fetch `User.name` from the one who has it as non-nullable. -This option supresses the warning, and takes the field from the schema that has it as non-nullable. - -```graphql - type Query { - user: User - } - - type User { - id: ID! - name: String - email: String - } -``` -And; - -```graphql - type Query { - user: User - } - - type User { - id: ID! - name: String! - } -``` - - diff --git a/.changeset/many-ads-run.md b/.changeset/many-ads-run.md deleted file mode 100644 index 4423c970cd5..00000000000 --- a/.changeset/many-ads-run.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -"@graphql-tools/federation": patch -"@graphql-tools/delegate": patch -"@graphql-tools/stitch": patch ---- - -If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly. - -Let's say subschema A has the following schema; - -```graphql - type Query { - user: User - } - - interface User { - id: ID! - name: String! - } - - type Admin implements User { - id: ID! - name: String! - role: String! - } - - type Customer implements User { - id: ID! - name: String - email: String - } -``` - -And let's say the gateway has the following schema instead; - -```graphql - type Query { - user: User - } - - interface User { - id: ID! - name: String! - } - - type Admin implements User { - id: ID! - name: String! - role: String! - } - - type Customer implements User { - id: ID! - name: String! - email: String! - } -``` - -In this case, the following query is fine for the gateway but for the subschema, it's not; - -```graphql - query { - user { - ... on Admin { - id - name # This is nullable in the subschema - role - } - ... on Customer { - id - name # This is non-nullable in the subschema - email - } - } - } -``` - -So the subgraph will throw based on this rule [OverlappingFieldsCanBeMerged](https://github.com/graphql/graphql-js/blob/main/src/validation/rules/OverlappingFieldsCanBeMergedRule.ts) - -To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following; - -```graphql - query { - user { - ... on Admin { - id - name # This is nullable in the subschema - role - } - ... on Customer { - id - name: _nullable_name # This is non-nullable in the subschema - email - } - } - } -``` diff --git a/.changeset/old-starfishes-shop.md b/.changeset/old-starfishes-shop.md deleted file mode 100644 index cc8b1bfe5ca..00000000000 --- a/.changeset/old-starfishes-shop.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -"@graphql-tools/delegate": patch -"@graphql-tools/stitch": patch ---- - -If one of the subgraphs are already able to resolve a nested field as in `parent-entity-call` example's `Category.details` from C's `Product`, resolve it from there instead of using type merging. - -```graphql - query { - product { - category { - details { # This is coming from C's Product, so resolve it from there instead of Type Merging - id - name - } - } - } - } -``` diff --git a/benchmark/federation/CHANGELOG.md b/benchmark/federation/CHANGELOG.md index 5231e16123f..4a7cb2f294a 100644 --- a/benchmark/federation/CHANGELOG.md +++ b/benchmark/federation/CHANGELOG.md @@ -1,5 +1,13 @@ # federation-benchmark +## 0.0.129 + +### Patch Changes + +- Updated dependencies [[`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4), [`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4), [`243c353`](https://github.com/ardatan/graphql-tools/commit/243c353412921cf0063f963ee46b9c63d2f33b41)]: + - @graphql-tools/stitch@9.2.0 + - @graphql-tools/federation@1.1.28 + ## 0.0.128 ### Patch Changes diff --git a/benchmark/federation/package.json b/benchmark/federation/package.json index d51fe4ee44d..89e45b10e4e 100644 --- a/benchmark/federation/package.json +++ b/benchmark/federation/package.json @@ -1,6 +1,6 @@ { "name": "federation-benchmark", - "version": "0.0.128", + "version": "0.0.129", "private": true, "scripts": { "loadtest:federation": "k6 -e ENDPOINT=federation run k6.js", @@ -11,8 +11,8 @@ "dependencies": { "@apollo/gateway": "2.7.4", "@apollo/subgraph": "2.7.4", - "@graphql-tools/federation": "1.1.27", - "@graphql-tools/stitch": "9.1.2", + "@graphql-tools/federation": "1.1.28", + "@graphql-tools/stitch": "9.2.0", "cross-env": "7.0.3", "express": "4.19.2", "graphql": "16.8.1", diff --git a/packages/delegate/CHANGELOG.md b/packages/delegate/CHANGELOG.md index b46f02ae234..4c58e2b1aa5 100644 --- a/packages/delegate/CHANGELOG.md +++ b/packages/delegate/CHANGELOG.md @@ -1,5 +1,117 @@ # @graphql-tools/delegate +## 10.0.5 + +### Patch Changes + +- [#6091](https://github.com/ardatan/graphql-tools/pull/6091) [`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4) Thanks [@User](https://github.com/User), [@User](https://github.com/User)! - If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly. + + Let's say subschema A has the following schema; + + ```graphql + type Query { + + } + + interface User { + id: ID! + name: String! + } + + type Admin implements User { + id: ID! + name: String! + role: String! + } + + type Customer implements User { + id: ID! + name: String + email: String + } + ``` + + And let's say the gateway has the following schema instead; + + ```graphql + type Query { + + } + + interface User { + id: ID! + name: String! + } + + type Admin implements User { + id: ID! + name: String! + role: String! + } + + type Customer implements User { + id: ID! + name: String! + email: String! + } + ``` + + In this case, the following query is fine for the gateway but for the subschema, it's not; + + ```graphql + query { + user { + ... on Admin { + id + name # This is nullable in the subschema + role + } + ... on Customer { + id + name # This is non-nullable in the subschema + email + } + } + } + ``` + + So the subgraph will throw based on this rule [OverlappingFieldsCanBeMerged](https://github.com/graphql/graphql-js/blob/main/src/validation/rules/OverlappingFieldsCanBeMergedRule.ts) + + To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following; + + ```graphql + query { + user { + ... on Admin { + id + name # This is nullable in the subschema + role + } + ... on Customer { + id + name: _nullable_name # This is non-nullable in the subschema + email + } + } + } + ``` + +- [#6092](https://github.com/ardatan/graphql-tools/pull/6092) [`243c353`](https://github.com/ardatan/graphql-tools/commit/243c353412921cf0063f963ee46b9c63d2f33b41) Thanks [@ardatan](https://github.com/ardatan)! - If one of the subgraphs are already able to resolve a nested field as in `parent-entity-call` example's `Category.details` from C's `Product`, resolve it from there instead of using type merging. + + ```graphql + query { + product { + category { + details { + # This is coming from C's Product, so resolve it from there instead of Type Merging + id + name + } + } + } + } + ``` + ## 10.0.4 ### Patch Changes diff --git a/packages/delegate/package.json b/packages/delegate/package.json index 86d5e724fab..9a45fc09f68 100644 --- a/packages/delegate/package.json +++ b/packages/delegate/package.json @@ -1,6 +1,6 @@ { "name": "@graphql-tools/delegate", - "version": "10.0.4", + "version": "10.0.5", "type": "module", "description": "A set of utils for faster development of GraphQL tools", "repository": { diff --git a/packages/federation/CHANGELOG.md b/packages/federation/CHANGELOG.md index e7d1413408b..c6965e13738 100644 --- a/packages/federation/CHANGELOG.md +++ b/packages/federation/CHANGELOG.md @@ -1,5 +1,105 @@ # @graphql-tools/federation +## 1.1.28 + +### Patch Changes + +- [#6091](https://github.com/ardatan/graphql-tools/pull/6091) [`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4) Thanks [@User](https://github.com/User), [@User](https://github.com/User)! - If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly. + + Let's say subschema A has the following schema; + + ```graphql + type Query { + + } + + interface User { + id: ID! + name: String! + } + + type Admin implements User { + id: ID! + name: String! + role: String! + } + + type Customer implements User { + id: ID! + name: String + email: String + } + ``` + + And let's say the gateway has the following schema instead; + + ```graphql + type Query { + + } + + interface User { + id: ID! + name: String! + } + + type Admin implements User { + id: ID! + name: String! + role: String! + } + + type Customer implements User { + id: ID! + name: String! + email: String! + } + ``` + + In this case, the following query is fine for the gateway but for the subschema, it's not; + + ```graphql + query { + user { + ... on Admin { + id + name # This is nullable in the subschema + role + } + ... on Customer { + id + name # This is non-nullable in the subschema + email + } + } + } + ``` + + So the subgraph will throw based on this rule [OverlappingFieldsCanBeMerged](https://github.com/graphql/graphql-js/blob/main/src/validation/rules/OverlappingFieldsCanBeMergedRule.ts) + + To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following; + + ```graphql + query { + user { + ... on Admin { + id + name # This is nullable in the subschema + role + } + ... on Customer { + id + name: _nullable_name # This is non-nullable in the subschema + email + } + } + } + ``` + +- Updated dependencies [[`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4), [`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4), [`243c353`](https://github.com/ardatan/graphql-tools/commit/243c353412921cf0063f963ee46b9c63d2f33b41)]: + - @graphql-tools/stitch@9.2.0 + - @graphql-tools/delegate@10.0.5 + ## 1.1.27 ### Patch Changes diff --git a/packages/federation/package.json b/packages/federation/package.json index 084a0a571d1..b44a4b25b0f 100644 --- a/packages/federation/package.json +++ b/packages/federation/package.json @@ -1,6 +1,6 @@ { "name": "@graphql-tools/federation", - "version": "1.1.27", + "version": "1.1.28", "type": "module", "description": "Useful tools to create and manipulate GraphQL schemas.", "repository": { @@ -50,11 +50,11 @@ "graphql": "^14.0.0 || ^15.0.0 || ^16.0.0 || ^17.0.0" }, "dependencies": { - "@graphql-tools/delegate": "^10.0.4", + "@graphql-tools/delegate": "^10.0.5", "@graphql-tools/executor-http": "^1.0.9", "@graphql-tools/merge": "^9.0.3", "@graphql-tools/schema": "^10.0.3", - "@graphql-tools/stitch": "^9.0.5", + "@graphql-tools/stitch": "^9.2.0", "@graphql-tools/utils": "^10.1.1", "@graphql-tools/wrap": "^10.0.3", "tslib": "^2.4.0", diff --git a/packages/stitch/CHANGELOG.md b/packages/stitch/CHANGELOG.md index 5f4e5396039..d035cd5d2fd 100644 --- a/packages/stitch/CHANGELOG.md +++ b/packages/stitch/CHANGELOG.md @@ -1,5 +1,152 @@ # @graphql-tools/stitch +## 9.2.0 + +### Minor Changes + +- [#6091](https://github.com/ardatan/graphql-tools/pull/6091) [`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4) Thanks [@User](https://github.com/User), [@User](https://github.com/User)! - New option `useNonNullableFieldOnConflict` in `typeMergingOptions` of `stitchSchemas` + + When you have two schemas like below, you will get a warning about the conflicting fields because `name` field is defined as non-null in one schema and nullable in the other schema, and non-nullable field can exist in the stitched schema because of the order or any other reasons, and this might actually cause an unexpected behavior when you fetch `User.name` from the one who has it as non-nullable. + This option supresses the warning, and takes the field from the schema that has it as non-nullable. + + ```graphql + type Query { + + } + + type User { + id: ID! + name: String + email: String + } + ``` + + And; + + ```graphql + type Query { + + } + + type User { + id: ID! + name: String! + } + ``` + +### Patch Changes + +- [#6091](https://github.com/ardatan/graphql-tools/pull/6091) [`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4) Thanks [@User](https://github.com/User), [@User](https://github.com/User)! - If the gateway receives a query with an overlapping fields for the subschema, it uses aliases to resolve it correctly. + + Let's say subschema A has the following schema; + + ```graphql + type Query { + + } + + interface User { + id: ID! + name: String! + } + + type Admin implements User { + id: ID! + name: String! + role: String! + } + + type Customer implements User { + id: ID! + name: String + email: String + } + ``` + + And let's say the gateway has the following schema instead; + + ```graphql + type Query { + + } + + interface User { + id: ID! + name: String! + } + + type Admin implements User { + id: ID! + name: String! + role: String! + } + + type Customer implements User { + id: ID! + name: String! + email: String! + } + ``` + + In this case, the following query is fine for the gateway but for the subschema, it's not; + + ```graphql + query { + user { + ... on Admin { + id + name # This is nullable in the subschema + role + } + ... on Customer { + id + name # This is non-nullable in the subschema + email + } + } + } + ``` + + So the subgraph will throw based on this rule [OverlappingFieldsCanBeMerged](https://github.com/graphql/graphql-js/blob/main/src/validation/rules/OverlappingFieldsCanBeMergedRule.ts) + + To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following; + + ```graphql + query { + user { + ... on Admin { + id + name # This is nullable in the subschema + role + } + ... on Customer { + id + name: _nullable_name # This is non-nullable in the subschema + email + } + } + } + ``` + +- [#6092](https://github.com/ardatan/graphql-tools/pull/6092) [`243c353`](https://github.com/ardatan/graphql-tools/commit/243c353412921cf0063f963ee46b9c63d2f33b41) Thanks [@ardatan](https://github.com/ardatan)! - If one of the subgraphs are already able to resolve a nested field as in `parent-entity-call` example's `Category.details` from C's `Product`, resolve it from there instead of using type merging. + + ```graphql + query { + product { + category { + details { + # This is coming from C's Product, so resolve it from there instead of Type Merging + id + name + } + } + } + } + ``` + +- Updated dependencies [[`9bca9e0`](https://github.com/ardatan/graphql-tools/commit/9bca9e03915a2e12d164e355be9aed389b0de3a4), [`243c353`](https://github.com/ardatan/graphql-tools/commit/243c353412921cf0063f963ee46b9c63d2f33b41)]: + - @graphql-tools/delegate@10.0.5 + ## 9.1.2 ### Patch Changes diff --git a/packages/stitch/package.json b/packages/stitch/package.json index 95df195a248..90121dcf669 100644 --- a/packages/stitch/package.json +++ b/packages/stitch/package.json @@ -1,6 +1,6 @@ { "name": "@graphql-tools/stitch", - "version": "9.1.2", + "version": "9.2.0", "type": "module", "description": "A set of utils for faster development of GraphQL tools", "repository": { @@ -51,7 +51,7 @@ }, "dependencies": { "@graphql-tools/batch-delegate": "^9.0.1", - "@graphql-tools/delegate": "^10.0.4", + "@graphql-tools/delegate": "^10.0.5", "@graphql-tools/executor": "^1.2.1", "@graphql-tools/merge": "^9.0.3", "@graphql-tools/schema": "^10.0.3",