Upcoming Release Changes

[theguild-bot]

This PR was opened by the Changesets release 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 master, this PR will be updated.

Releases

@graphql-tools/delegate@10.0.10

Patch Changes

• #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

@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 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]:

  • @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 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]:

  • @graphql-tools/delegate@10.0.10

federation-benchmark@0.0.139

Patch Changes

• Updated dependencies [a83da08, fc9c71f, cd962c1, 04d5431]:
  • @graphql-tools/stitch@9.2.8
  • @graphql-tools/federation@1.1.35

[github-actions]

🚀 Snapshot Release (rc)

The latest changes of this PR are available as rc on npm (based on the declared changesets):

Package	Version	Info
@graphql-tools/delegate	10.0.10-rc-20240508113004-77549fc98948dcda3091c90533e6aa84fddd5f54	npm ↗︎ unpkg ↗︎
@graphql-tools/federation	1.1.35-rc-20240508113004-77549fc98948dcda3091c90533e6aa84fddd5f54	npm ↗︎ unpkg ↗︎
@graphql-tools/stitch	9.2.8-rc-20240508113004-77549fc98948dcda3091c90533e6aa84fddd5f54	npm ↗︎ unpkg ↗︎

[github-actions]

✅ Benchmark Results

     ✓ no_errors
     ✓ expected_result

     checks.........................: 100.00% ✓ 342       ✗ 0  
     data_received..................: 40 MB   4.0 MB/s
     data_sent......................: 146 kB  15 kB/s
     http_req_blocked...............: avg=3.97µs   min=2.13µs   med=2.59µs  max=198.04µs p(90)=3.67µs  p(95)=3.97µs  
     http_req_connecting............: avg=728ns    min=0s       med=0s      max=124.59µs p(90)=0s      p(95)=0s      
     http_req_duration..............: avg=54.39ms  min=46.47ms  med=50.37ms max=141.85ms p(90)=60.39ms p(95)=88.97ms 
       { expected_response:true }...: avg=54.39ms  min=46.47ms  med=50.37ms max=141.85ms p(90)=60.39ms p(95)=88.97ms 
     http_req_failed................: 0.00%   ✓ 0         ✗ 171
     http_req_receiving.............: avg=142.47µs min=105.49µs med=130.7µs max=1.04ms   p(90)=157.7µs p(95)=190.44µs
     http_req_sending...............: avg=28.93µs  min=19.44µs  med=22.8µs  max=774.81µs p(90)=29.61µs p(95)=33.24µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s      max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=54.22ms  min=46.32ms  med=50.21ms max=141.44ms p(90)=60.23ms p(95)=88.81ms 
     http_reqs......................: 171     17.041448/s
     iteration_duration.............: avg=58.66ms  min=50.27ms  med=54.46ms max=148.54ms p(90)=66.77ms p(95)=92.64ms 
     iterations.....................: 171     17.041448/s
     vus............................: 1       min=1       max=1
     vus_max........................: 1       min=1       max=1

[github-actions]

💻 Website Preview

The latest changes are available as preview in: https://0446c887.graphql-tools.pages.dev