:wrench: Utility library for GraphQL to build, stitch and mock GraphQL schemas in the SDL-first approach
#6134 a83da08 Thanks @User! - Ignore unmerged fields
Let's say you have a gateway schema like in the bottom, and id is added to the query, only if the age 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 see ProductList needs some fields from Product to resolve first
#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 is node(id: ID!): Node in all subgraphs but one implements User and the other implements Post, the gateway will choose the subgraph that implements User or Post 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]:
#6134 a83da08 Thanks @User! - Ignore unmerged fields
Let's say you have a gateway schema like in the bottom, and id is added to the query, only if the age 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 see ProductList needs some fields from Product to resolve first
#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 is node(id: ID!): Node in all subgraphs but one implements User and the other implements Post, the gateway will choose the subgraph that implements User or Post 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]:
508ae6b Thanks @ardatan! - Support overrides on interfaces
See packages/federation/test/fixtures/federation-compatibility/override-type-interface/supergraph.graphql for more details#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!
}
#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]:
#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]:
98b2795 Thanks @ardatan! - Improvements on unavailable field selection, and key object projection
Updated dependencies [98b2795]:
9238e14 Thanks @ardatan! - Improvements on field merging and extraction of unavailable fields
Updated dependencies [9238e14, 4ce3ffc]:
9238e14 Thanks @ardatan! - Improvements on field merging and extraction of unavailable fields
Updated dependencies [4ce3ffc]:
a06dbd2 Thanks @lesleydreyer! - Fix directive merging when directive name is inherited from object prototype (i.e. toString)#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 using Product resolver instead of trying to resolve by using non-existing Category resolver from A Subschema.
Previously, the query planner decides to resolve Category.details after resolving Category from C Subschema. But it will be too late to resolve details because Category is not resolvable in A Subschema.
So the requests for Category.details and the rest of Category 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]:
#6109 074fad4 Thanks @ardatan! - Show responses in debug logging with DEBUG env var
Updated dependencies [074fad4, 074fad4]:
#6109 074fad4 Thanks @ardatan! - Exclude fields with __typename while extracting missing fields for the type merging
Updated dependencies [074fad4]:
#6105 5567347 Thanks @ardatan! - Handle fields in unmerged types as both isolated and non-isolated fields
#6105 5567347 Thanks @ardatan! - Respect specifiedByURL in stitched schemas
Updated dependencies [5567347, 5567347]: