Skip to content

April 26, 2024
Compare
Choose a tag to compare
@theguild-bot theguild-bot released this 26 Apr 12:42
· 78 commits to master since this release
release-1714135357803
3d5323d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

@graphql-tools/delegate@10.0.5

Patch Changes

  • #6091 9bca9e0 Thanks @User, @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;

      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;

      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;

    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

    To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following;

    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 243c353 Thanks @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.

    query {
  product {
    category {
      details {
        # This is coming from C's Product, so resolve it from there instead of Type Merging
        id
        name
      }
    }
  }
}

@graphql-tools/federation@1.1.28

Patch Changes

  • #6091 9bca9e0 Thanks @User, @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;

      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;

      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;

    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

    To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following;

    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, 9bca9e0, 243c353]:

    • @graphql-tools/stitch@9.2.0
    • @graphql-tools/delegate@10.0.5

@graphql-tools/stitch@9.2.0

Minor Changes

  • #6091 9bca9e0 Thanks @User, @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.

      type Query {

  }

  type User {
    id: ID!
    name: String
    email: String
  }

    And;

      type Query {

  }

  type User {
    id: ID!
    name: String!
  }

Patch Changes

  • #6091 9bca9e0 Thanks @User, @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;

      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;

      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;

    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

    To avoid this, the gateway will use aliases to resolve the query correctly. The query will be transformed to the following;

    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 243c353 Thanks @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.

    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, 243c353]:

    • @graphql-tools/delegate@10.0.5
Assets 2