Releases: ardatan/graphql-tools
May 27, 2024
@graphql-tools/batch-delegate@9.0.3
Patch Changes
-
#6194
7368829
Thanks @ardatan! - Handle interface objects in a different way -
Updated dependencies
[7368829
,
e10c13a
,
e10c13a
,
dfccfbf
,
0134f7f
]:- @graphql-tools/delegate@10.0.11
- @graphql-tools/utils@10.2.1
@graphql-tools/delegate@10.0.11
Patch Changes
-
#6194
7368829
Thanks @ardatan! - Handle interface objects in a different way -
#6188
e10c13a
Thanks @ardatan! - AddsubtractSelectionSets
to get the diff of
two selection sets -
#6187
dfccfbf
Thanks @ardatan! - Do not merge errors and regular resolved objectsIf a subschema returns an error for specific field that is already resolved by another subschema,
the error should not be merged with the resolved object. -
#6189
0134f7f
Thanks @ardatan! - Handle interface types with non-shared
implementations;For example, you have the following services, where
Node
is implemented in both services, but
Foo
andBar
are only implemented in one service. And when the gateway receives the following
query, it should be converted to this becauseNode
is not implemented asBar
in Service 1
while implemented in Service 2.Query conversion;
# Gateway request query { fooBar(id: "1") { ... on Node { id } } }
# Service 1 Request query { fooBar(id: "1") { ... on Foo { id } ... on Bar { id } } }
Services;
# Service 1 union FooBar = Foo | Bar interface Node { id: ID! } type Foo implements Node { id: ID! } type Bar { id: ID! } type Query { fooBar(id: ID!): FooBar }
# Service 2 interface Node { id: ID! } type Foo implements Node { id: ID! } type Bar implements Node { id: ID! }
-
Updated dependencies
[7368829
,
e10c13a
]:- @graphql-tools/schema@10.0.4
- @graphql-tools/utils@10.2.1
@graphql-tools/federation@1.1.36
Patch Changes
-
#6194
7368829
Thanks @ardatan! - Handle interface objects in a different way -
#6189
0134f7f
Thanks @ardatan! - Handle interface types with non-shared
implementations;For example, you have the following services, where
Node
is implemented in both services, but
Foo
andBar
are only implemented in one service. And when the gateway receives the following
query, it should be converted to this becauseNode
is not implemented asBar
in Service 1
while implemented in Service 2.Query conversion;
# Gateway request query { fooBar(id: "1") { ... on Node { id } } }
# Service 1 Request query { fooBar(id: "1") { ... on Foo { id } ... on Bar { id } } }
Services;
# Service 1 union FooBar = Foo | Bar interface Node { id: ID! } type Foo implements Node { id: ID! } type Bar { id: ID! } type Query { fooBar(id: ID!): FooBar }
# Service 2 interface Node { id: ID! } type Foo implements Node { id: ID! } type Bar implements Node { id: ID! }
-
#6187
dfccfbf
Thanks @ardatan! - Respect @provides to optimize the query plan -
#6188
e10c13a
Thanks @ardatan! - If two different subschemas have the root field,
use the same field to resolve missing fields instead of applying a type merging in advance -
Updated dependencies
[7368829
,
e10c13a
,
e10c13a
,
dfccfbf
,
0134f7f
,
eec9d3d
,
03a47b1
,
e10c13a
,
0827497
]:- @graphql-tools/delegate@10.0.11
- @graphql-tools/schema@10.0.4
- @graphql-tools/stitch@9.2.9
- @graphql-tools/utils@10.2.1
@graphql-tools/mock@9.0.3
Patch Changes
-
#6201
9d79b3e
Thanks @grxy! - perf: only clone schema once inaddMocksToSchema
-
Updated dependencies
[7368829
,
e10c13a
]:- @graphql-tools/schema@10.0.4
- @graphql-tools/utils@10.2.1
@graphql-tools/schema@10.0.4
Patch Changes
-
#6194
7368829
Thanks @ardatan! - Handle interface objects in a different way -
Updated dependencies
[7368829
,
e10c13a
]:- @graphql-tools/utils@10.2.1
@graphql-tools/stitch@9.2.9
Patch Changes
-
#6194
7368829
Thanks @ardatan! - Handle interface objects in a different way -
#6180
eec9d3d
Thanks @ardatan! - Handle nested dependencies in the computed fields{ merge: { Product: { selectionSet: '{ id }', fields: { isExpensive: { selectionSet: '{ price }', computed: true, }, canAfford: { selectionSet: '{ isExpensive }', computed: true, }, } } } }
-
#6179
03a47b1
Thanks @ardatan! - Support computed fields resolved via a root field
returning an interface When a computed field returning an object, and that field is resolved via
an interface, the computed field will now be resolved correctly.
May 14, 2024
@graphql-tools/graphql-tag-pluck@8.3.1
Patch Changes
- #4439
ee0daab
Thanks @jaschaephraim! - Add option to pluck from custom Vue block
@graphql-tools/code-file-loader@8.1.2
Patch Changes
- Updated dependencies [
ee0daab
]:- @graphql-tools/graphql-tag-pluck@8.3.1
@graphql-tools/git-loader@8.0.6
Patch Changes
- Updated dependencies [
ee0daab
]:- @graphql-tools/graphql-tag-pluck@8.3.1
May 08, 2024
@graphql-tools/delegate@10.0.10
Patch Changes
-
#6134
a83da08
Thanks @User! - Ignore unmerged fieldsLet's say you have a gateway schema like in the bottom, and
id
is added to the query, only if theage
is requested;# This will be sent as-is { user { name } }
But the following will be transformed;
{ user { name age } }
Into
{ user { id name age } }
type Query {
}
type User {
id: ID! # is the key for all services
name: String!
age: Int! # This comes from another service
}
-
#6150
fc9c71f
Thanks @ardatan! - If there are some fields depending on a nested type resolution, wait until it gets resolved then resolve the rest.See packages/federation/test/fixtures/complex-entity-call example for more details.
You can seeProductList
needs some fields fromProduct
to resolvefirst
@graphql-tools/federation@1.1.35
Patch Changes
-
#6141
cd962c1
Thanks @ardatan! - When the gateway receives the query, now it chooses the best root field if there is the same root field in different subgraphs.
For example, if there isnode(id: ID!): Node
in all subgraphs but one implementsUser
and the other implementsPost
, the gateway will choose the subgraph that implementsUser
orPost
based on the query.If there is a unresolvable interface field, it throws.
See this supergraph and the test query to see a real-life example
-
#6143
04d5431
Thanks @ardatan! - Implement interface objects support -
Updated dependencies [
a83da08
,fc9c71f
,cd962c1
]:- @graphql-tools/delegate@10.0.10
- @graphql-tools/stitch@9.2.8
@graphql-tools/stitch@9.2.8
Patch Changes
-
#6134
a83da08
Thanks @User! - Ignore unmerged fieldsLet's say you have a gateway schema like in the bottom, and
id
is added to the query, only if theage
is requested;# This will be sent as-is { user { name } }
But the following will be transformed;
{ user { name age } }
Into
{ user { id name age } }
type Query {
}
type User {
id: ID! # is the key for all services
name: String!
age: Int! # This comes from another service
}
-
#6150
fc9c71f
Thanks @ardatan! - If there are some fields depending on a nested type resolution, wait until it gets resolved then resolve the rest.See packages/federation/test/fixtures/complex-entity-call example for more details.
You can seeProductList
needs some fields fromProduct
to resolvefirst
-
#6141
cd962c1
Thanks @ardatan! - When the gateway receives the query, now it chooses the best root field if there is the same root field in different subgraphs.
For example, if there isnode(id: ID!): Node
in all subgraphs but one implementsUser
and the other implementsPost
, the gateway will choose the subgraph that implementsUser
orPost
based on the query.If there is a unresolvable interface field, it throws.
See this supergraph and the test query to see a real-life example
-
Updated dependencies [
a83da08
,fc9c71f
]:- @graphql-tools/delegate@10.0.10
May 02, 2024
@graphql-tools/federation@1.1.34
Patch Changes
- #6130
508ae6b
Thanks @ardatan! - Support overrides on interfaces
See packages/federation/test/fixtures/federation-compatibility/override-type-interface/supergraph.graphql for more details
May 02, 2024
May 02, 2024
@graphql-tools/delegate@10.0.9
Patch Changes
-
#6126
680351e
Thanks @ardatan! - When there is a Node subschema, and others to resolve the rest of the entities by using a union resolver as in Federation like below, it was failing. This version fixes that issue.query { node(id: "1") { id # Fetches from Node ... on User { name # Fetches from User } } }
type Query { node(id: ID!): Node } interface Node { id: ID! } type User implements Node { id: ID! } type Post implements Node { id: ID! }
# User subschema scalar _Any type Query { _entities(representations: [_Any!]!): [_Entity]! } union _Entity = User interface Node { id: ID! } type User implements Node { id: ID! name: String! }
# Post subschema scalar _Any union _Entity = Post type Query { _entities(representations: [_Any!]!): [_Entity]! } interface Node { id: ID! } type Post implements Node { id: ID! title: String! }
@graphql-tools/federation@1.1.32
Patch Changes
-
#6126
680351e
Thanks @ardatan! - When there is a Node subschema, and others to resolve the rest of the entities by using a union resolver as in Federation like below, it was failing. This version fixes that issue.query { node(id: "1") { id # Fetches from Node ... on User { name # Fetches from User } } }
type Query { node(id: ID!): Node } interface Node { id: ID! } type User implements Node { id: ID! } type Post implements Node { id: ID! }
# User subschema scalar _Any type Query { _entities(representations: [_Any!]!): [_Entity]! } union _Entity = User interface Node { id: ID! } type User implements Node { id: ID! name: String! }
# Post subschema scalar _Any union _Entity = Post type Query { _entities(representations: [_Any!]!): [_Entity]! } interface Node { id: ID! } type Post implements Node { id: ID! title: String! }
-
Updated dependencies [
680351e
]:- @graphql-tools/delegate@10.0.9
- @graphql-tools/stitch@9.2.7
@graphql-tools/stitch@9.2.7
Patch Changes
-
#6126
680351e
Thanks @ardatan! - When there is a Node subschema, and others to resolve the rest of the entities by using a union resolver as in Federation like below, it was failing. This version fixes that issue.query { node(id: "1") { id # Fetches from Node ... on User { name # Fetches from User } } }
type Query { node(id: ID!): Node } interface Node { id: ID! } type User implements Node { id: ID! } type Post implements Node { id: ID! }
# User subschema scalar _Any type Query { _entities(representations: [_Any!]!): [_Entity]! } union _Entity = User interface Node { id: ID! } type User implements Node { id: ID! name: String! }
# Post subschema scalar _Any union _Entity = Post type Query { _entities(representations: [_Any!]!): [_Entity]! } interface Node { id: ID! } type Post implements Node { id: ID! title: String! }
-
Updated dependencies [
680351e
]:- @graphql-tools/delegate@10.0.9
May 02, 2024
May 02, 2024
@graphql-tools/delegate@10.0.8
Patch Changes
@graphql-tools/federation@1.1.30
Patch Changes
-
9238e14
Thanks @ardatan! - Improvements on field merging and extraction of unavailable fields -
Updated dependencies [
9238e14
,4ce3ffc
]:- @graphql-tools/stitch@9.2.5
- @graphql-tools/delegate@10.0.8
@graphql-tools/stitch@9.2.5
Patch Changes
April 30, 2024
@graphql-tools/merge@9.0.4
Patch Changes
- #6111
a06dbd2
Thanks @lesleydreyer! - Fix directive merging when directive name is inherited from object prototype (i.e. toString)
@graphql-tools/stitch@9.2.4
Patch Changes
-
#6117
67a9c49
Thanks @ardatan! - Add field as an unavailable field only if it is not able to resolve by any other subschema;When the following query is sent to the gateway with the following subschemas, the gateway should resolve
Category.details
from A Subschema usingProduct
resolver instead of trying to resolve by using non-existingCategory
resolver from A Subschema.Previously, the query planner decides to resolve
Category.details
after resolvingCategory
from C Subschema. But it will be too late to resolvedetails
becauseCategory
is not resolvable in A Subschema.So the requests for
Category.details
and the rest ofCategory
should be different.So for the following query, we expect a full result;
query { productFromA(id: "1") { id name category { id name details } } }
# A Subschema type Query { productFromA(id: ID): Product # No category resolver is present } type Product { id: ID category: Category } type Category { details: CategoryDetails }
# B Subschema type Query { productFromB(id: ID): Product } type Product { id: ID name: String category: Category } type Category { id: ID }
# C Subschema type Query { categoryFromC(id: ID): Category } type Category { id: ID name: String }
-
Updated dependencies [
a06dbd2
]:- @graphql-tools/merge@9.0.4
April 29, 2024
@graphql-tools/delegate@10.0.7
Patch Changes
@graphql-tools/federation@1.1.29
Patch Changes
-
#6109
074fad4
Thanks @ardatan! - Show responses in debug logging withDEBUG
env var -
Updated dependencies [
074fad4
,074fad4
]:- @graphql-tools/delegate@10.0.7
- @graphql-tools/stitch@9.2.3