A set of utils for faster development of GraphQL tools
A fully open-source MIT-licensed GraphQL API gateway that can act as a GraphQL federation Gateway or a Proxy Gateway for any GraphQL services.
It can be run as a standalone binary, a Docker Image, or as a JavaScript package (e.g. within Node.js, Bun, Deno, Google Cloud Functions, Azure Functions or Cloudflare Workers)
graphql-hive4a80de1, f634b53, dca6529]:0512be3 Thanks @ardatan! - Optimizes @provides handling by avoiding the generation of new query plans when a parent subgraph already supplies the requested fields.subtractSelectionSets to compute leftover selections.providedSelectionNode through planning to subtract out provided fields early.0512be3]:#950 c7ea2c5 Thanks @kroupacz! - Errors should not be swallowed when it is thrown from the shared root
Updated dependencies [c7ea2c5, 0af3485]:
#532 4e33933 Thanks @EmrysMyrddin! - dependencies updates:
@whatwg-node/promise-helpers@^1.3.0 ↗︎ (from ^1.2.5, in dependencies)#906 7b86c09 Thanks @ardatan! - Extract unavailable fields for the target subschema from the fragments provided in the original query
Updated dependencies [4e33933, 4e33933, 4e33933]:
#862 278618a Thanks @ardatan! - dependencies updates:
@whatwg-node/promise-helpers@^1.2.5 ↗︎ (from ^1.0.0, in dependencies)Updated dependencies [278618a, 278618a, 278618a]:
#726 6334b2e Thanks @ardatan! - dependencies updates:
@whatwg-node/promise-helpers@^1.0.0 ↗︎ (to dependencies)Updated dependencies [6334b2e, 6334b2e, 6334b2e, 2a54e85]:
2318393]:#620 d72209a Thanks @renovate! - dependencies updates:
@graphql-tools/utils@^10.8.1 ↗︎ (from ^10.7.0, in dependencies)#614 7146f8d Thanks @ardatan! - Fix a bug while isolating computed abstract type fields
When a field in an interface needs to be isolated, it should not remove the field from the base subschema if it is used by other members of the base subschema.
#614 7146f8d Thanks @ardatan! - While calculating the best subschema for a selection set, respect fragments
Updated dependencies [d72209a, d72209a, d72209a]:
9144222]:18682e6, e9f78cd]:da65b2d]:21e1f05]:#373 e606975 Thanks @ardatan! - dependencies updates:
@graphql-tools/executor@^1.3.10 ↗︎ (from ^1.3.6, in dependencies)@graphql-tools/utils@^10.7.0 ↗︎ (from ^10.6.2, in dependencies)Updated dependencies [e606975, e606975, e606975]:
23b8987]:#291 34d1224 Thanks @ardatan! - dependencies updates:
tslib@^2.8.1 ↗︎ (from ^2.4.0, in dependencies)Updated dependencies [34d1224, 34d1224, 34d1224]:
#269 cdca511 Thanks @ardatan! - dependencies updates:
@graphql-tools/executor@^1.3.6 ↗︎ (from ^1.3.3, in dependencies)@graphql-tools/merge@^9.0.12 ↗︎ (from ^9.0.9, in dependencies)@graphql-tools/schema@^10.0.11 ↗︎ (from ^10.0.8, in dependencies)@graphql-tools/utils@^10.6.2 ↗︎ (from ^10.6.0, in dependencies)Updated dependencies [6f56083, 7df2215, cdca511, 7df2215, cdca511, cdca511]:
9ce705c]:#231 7ca0ff3 Thanks @ardatan! - Avoid extensions and use `stitchingInfo` for provided fields
Updated dependencies [7ca0ff3]:
#205 2e0add3 Thanks @ardatan! - Fix missing key fields in the nested queries
Updated dependencies [2e0add3]:
#164 310613d Thanks @ardatan! - dependencies updates:
@graphql-tools/utils@^10.6.0 ↗︎ (from ^10.5.6, in dependencies)#185 f0b6921 Thanks @ardatan! - dependencies updates:
value-or-promise@^1.0.11 ↗︎ (from dependencies)#188 f71366d Thanks @ardatan! - dependencies updates:
value-or-promise@^1.0.11 ↗︎ (from dependencies)Updated dependencies [310613d, f0b6921, f71366d, 310613d, 310613d, f0b6921, f71366d]:
f32cb2a Thanks @ardatan! - Introduce `onDelegationPlan` and `onDelegationStageExecuteDone` hooksf32cb2a]:73c621d, 19bc6a4]:342e044]:e9906eb]:da1de08]:f470f49]:180f3f0
Thanks @ardatan! - Avoid extra calls if the keys are already
resolved
Updated dependencies
[180f3f0]:
8effad4]:8a16b01]:4cdb462]:#6573
7e2938d
Thanks @ardatan! - When there are two services like below then the
following query senty, the gateway tries to fetch id as an extra field because it considers id
might be needed while this is not correct. This patch avoids any extra calls, and forwards the
query as is to the 2nd service.
query {
viewer {
booksContainer(input: $input) {
edges {
cursor
node {
source {
# Book(upc=)
upc
}
}
}
pageInfo {
endCursor
}
}
}
}
type Book @key(fields: "id") @key(fields: "upc") {
id: ID!
upc: ID!
}
type BookContainer { # the type that is used in a collection
id: ID!
# ... other stuff here
source: Book!
}
type Book @key(fields: "upc") {
upc: ID!
}
type Query {
viewer: Viewer
}
type Viewer {
booksContainer: BooksContainerResult
}
type BooksContainerResult {
edges: [BooksContainerEdge!]!
pageInfo: PageInfo!
}
type BooksContainerEdge {
node: BookContainer!
cursor: String!
}
type PageInfo {
endCursor: String
}
Updated dependencies
[7e2938d]:
#6543
dcb3e27
Thanks @enisdenjo! - Isolate computed fields return objects only
if not referenced from other, non-isolated, objects
Updated dependencies
[cf2ce5e]:
#6293
3f301dc
Thanks @ardatan! - Do not apply isolation for Mutation fields
Updated dependencies
[66c99d9,
74f995f]:
#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.
#6188
e10c13a
Thanks @ardatan! - Handle nested selections in
calculateSelectionScore
#6175
0827497
Thanks @ardatan! - If there is a subschema with some selection set,
and another with some other selection set. After the calculation of delegation stage, if one
subschema can cover the other selection set as well, then we can merge the two selection sets into
one, and remove the other subschema from the stage.
7368829,
e10c13a,
e10c13a,
dfccfbf,
0134f7f]:#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
````graphql { 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]:
#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]:
9238e14
Thanks @ardatan! - Improvements on field merging and extraction of
unavailable fields
Updated dependencies
[4ce3ffc]:
#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! - 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]:
#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!
}
#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]:
27b6f49
Thanks @asodeur! - Adding the ability to return non-scalar types
from computed fields. Computed fields can now return object types (local or stitched), interfaces,
unions, or enums.83c0af0
Thanks @enisdenjo! - dependencies updates:@graphql-tools/delegate@^10.0.3 ↗︎
(from ^10.0.1, in dependencies)@graphql-tools/merge@^9.0.1 ↗︎
(from ^9.0.0, in dependencies)@graphql-tools/schema@^10.0.2 ↗︎
(from ^10.0.0, in dependencies)@graphql-tools/utils@^10.0.13 ↗︎
(from ^10.0.0, in dependencies)@graphql-tools/wrap@^10.0.1 ↗︎
(from ^10.0.0, in dependencies)83c0af0,
83c0af0,
83c0af0,
83c0af0,
83c0af0,
83c0af0,
83c0af0]:cda328c3
Thanks @ardatan! - Support for multiple key entrypoints for an
object, and avoid sending whole object if possible#5474
f31be313
Thanks @ardatan! - Optimizations for federation
Updated dependencies
[f31be313]:
8fba6cc1,
944a68e8,
944a68e8,
944a68e8]:#5235
2bbbe1af
Thanks @belgattitude! - Add missing dependency on
@graphql-tools/executor.
Updated dependencies
[33005c48]:
Updated dependencies
[8e80b689]:
1c95368a
Thanks @ardatan! - Use ranged versions for dependencies
Updated dependencies
[1c95368a]:
c8d5e0df]:68c158d2]:f26392a6]:1913bf91]:04e3ecb9]:492220cb]:30bd4d0c,
30bd4d0c]:b09ea282,
b09ea282,
85659bca,
b5c8f640]:a94217e9,
62d074be]:772b948a]:8555c5c5]:fdb3e4c4
Thanks @ardatan! - Fix enum value transformation with
stitchSchemas
Updated dependencies
[fdb3e4c4]:
a4d36fcc,
a4d36fcc,
a4d36fcc,
499365aa,
e3ec35ed]:13177794]:55e24643]:eb6cd8b6,
eb6cd8b6]:904fe770,
904fe770]:13c24883,
b5e6459f]:02126e63]:7aa610ae]:5bd8c0dc]:e3f81ea5]:df81034c]:7411a5e7]:1270b75a,
c0639dd0]:a58cd6d3]:d83b1960]:#4796
80836fa7
Thanks @saihaj! - update collectFields to support collecting
deffered values
Updated dependencies
[80836fa7,
8f6d3efc,
80836fa7,
80836fa7,
80836fa7]:
f7daf777,
c1d01f3d]:df5848b8,
df5848b8,
df5848b8,
df5848b8]:0402894d]:614a5622,
00c4a1a4]:c21a895a]:43c736bd,
43c736bd]:dd8886d1]:71cb4fae,
403ed450]:4fe3d9c0,
4e4fac0a]:#4640
27bdc237
Thanks @ardatan! - dependencies updates:
@graphql-tools/batch-delegate@8.3.5 ↗︎
(was 8.3.4, in dependencies)@graphql-tools/delegate@9.0.3 ↗︎
(was 9.0.2, in dependencies)@graphql-tools/wrap@9.0.3 ↗︎
(was 9.0.2, in dependencies)Updated dependencies
[27bdc237,
27bdc237]:
Updated dependencies
[0555a972]:
#4648
29ee7542
Thanks @ardatan! - Do not call Transform.transformSchema more than
once
Updated dependencies
[29ee7542]:
2609d71f]:#4624
e3167edc
Thanks @n1ru4l! - Fix CommonJS TypeScript resolution with
moduleResolution node16 or nodenext
Updated dependencies
[8cc8721f,
e3167edc,
d8dc67aa]:
0bbb1769: Refine generic typings using extends X when appropriate
Typescript 4.7 has stricter requirements around generics which is explained well in the related PR: https://github.com/microsoft/TypeScript/pull/48366
These changes resolve the errors that these packages will face when attempting to upgrade to TS 4.7 (still in beta at the time of writing this). Landing these changes now will allow other TS libraries which depend on these packages to experiment with TS 4.7 in the meantime.
Updated dependencies [0bbb1769]
631b11bd: refactor(delegationPlanner): introduce static version of our piecemeal planner
...which, although undocumented, can be accessed within the StitchingInfo object saved in a stitched schema's extensions.
Also improves memoization technique slightly across the board.
67691b78: - schemaExtensions option has been added to mergeSchemas, makeExecutableSchema and
stitchSchemas configurations
Breaking Changes;
mergeSchemas and MergeSchemasConfig from @graphql-tools/merge to
@graphql-tools/schema package to prevent circular dependency between them.mergeSchemasAsync has been removed.NamedDefinitionNode, resetComments, collectComment, pushComment and printComment
from @graphql-tools/merge to @graphql-tools/utils.dae6dc7b: refactor: ExecutionParams type replaced by Request type
rootValue property is now a part of the Request type.
When delegating with delegateToSchema, rootValue can be set multiple ways:
When using wrapSchema/stitchSchemas, a subschemaConfig can specify the createProxyingResolver function which can pass whatever rootValue it wants to delegateToSchema as above.
74581cf3: fix(getDirectives): preserve order around repeatable directives
BREAKING CHANGE: getDirectives now always return an array of individual DirectiveAnnotation
objects consisting of name and args properties.
New useful function getDirective returns an array of objects representing any args for each use
of a single directive (returning the empty object {} when a directive is used without
arguments).
Note: The getDirective function returns an array even when the specified directive is
non-repeatable. This is because one use of this function is to throw an error if more than one
directive annotation is used for a non repeatable directive!
When specifying directives in extensions, one can use either the old or new format.
c0ca3190: BREAKING CHANGE
Executor can receive AsyncIterable and subscriptions will also be handled by
Executor. This is a future-proof change for defer, stream and live queries6aed1714: Allows MergedTypeConfig to be written with an entryPoints array for multiple merged
type entry points, each with their own fieldName and selectionSet:
{
schema: testSchema,
merge: {
Product: {
entryPoints: [{
selectionSet: '{ id }',
fieldName: 'productById',
key: ({ id, price, weight }) => ({ id, price, weight }),
argsFromKeys: (key) => ({ key }),
}, {
selectionSet: '{ upc }',
fieldName: 'productByUpc',
key: ({ upc, price, weight }) => ({ upc, price, weight }),
argsFromKeys: (key) => ({ key }),
}],
}
}
}
These multiple entry points accommodate types with multiple keys across services that rely on a central service to join them, for example:
type Product { upc }type Product { upc id }type Product { id }Given this graph, the possible traversals require the Vendors service to provide entry points for each unique key format:
Catalog > Vendors > ReviewsCatalog < Vendors > ReviewsCatalog < Vendors < ReviewsIs it highly recommended that you enable query batching for subschemas with multiple entry points.
Updated dependencies [6aed1714]
0194118f: Introduces a suite of stitched schema validations that enforce the integrity of merged schemas. This includes validations for:
Validations may be adjusted by setting validationLevel to off|warn|error globally or scoped
for specific types and fields. In this initial v7 release, all validations are introduced at the
warn threshold for backwards compatibility. Most of these validations will become automatic
errors in v8. To enable validation errors now, set validationLevel: 'error'. Full configuration
options look like this:
const gatewaySchema = stitchSchemas({
subschemas: [...],
typeMergingOptions: {
validationSettings: {
validationLevel: 'error',
strictNullComparison: false, // << gateway "String" may proxy subschema "String!"
proxiableScalars: {
ID: ['String'], // << gateway "ID" may proxy subschema "String"
}
},
validationScopes: {
// scope to specific element paths
'User.id': {
validationLevel: 'warn',
strictNullComparison: true,
},
}
},
});
24926654: Deprecates the MergeTypeConfig.computedFields setting (with backwards-compatible
warning) in favor of new computed field configuration written as:
merge: {
MyType: {
fields: {
myComputedField: {
selectionSet: '{ weight }',
computed: true,
}
}
}
}
A field-level selectionSet specifies field dependencies while the computed setting structures
the field in a way that assures it is always selected with this data provided. The selectionSet
is intentionally generic to support possible future uses. This new pattern organizes all
field-level configuration (including canonical) into a single structure.
6a966bee: fix(stitch): add __typename for mutations
fix related to #2349
6e50d9fc: enhance(stitching-directives): use keyField
When using simple keys, i.e. when using the keyField argument to @merge, the keyField can be
added implicitly to the types's key. In most cases, therefore, @key should not be required at
all.
Updated dependencies [6e50d9fc]
06a6acbe: fix(stitch): computed fields should work with merge resolvers that return abstract types
see: https://github.com/ardatan/graphql-tools/pull/2432#issuecomment-753729191 and: https://github.com/gmac/schema-stitching-handbook/pull/17
cd5da458: fix(stitch): type merging for nested root types
Because root types do not usually require selectionSets, a nested root type proxied to a remote service may end up having an empty selectionSet, if the nested root types only includes fields from a different subservice.
Empty selection sets return null, but, in this case, it should return an empty object. We can force this behavior by including the __typename field which exists on every schema.
Addresses #2347.
In the future, we may want to include short-circuiting behavior that when delegating to composite fields, if an empty selection set is included, an empty object is returned rather than null. This short-circuiting behavior would be complex for lists, as it would be unclear the length of the list...
Updated dependencies [cd5da458]
718eda30: fix(stitch): fix mergeExternalObject regressions
v7 introduced a regression in the merging of ExternalObjects that causes type merging to fail when undergoing multiple rounds of merging.
Updated dependencies [718eda30]
be1a1575: ## Breaking Changes:
@graphql-tools/schema)Resolver validation options should now be set to error, warn or ignore rather than true
or false. In previous versions, some of the validators caused errors to be thrown, while some
issued warnings. This changes brings consistency to validator behavior.
The allowResolversNotInSchema has been renamed to requireResolversToMatchSchema, to
harmonize the naming convention of all the validators. The default setting of
requireResolversToMatchSchema is error, matching the previous behavior.
delegateToSchema & @graphql-tools/delegate)The delegateToSchema return value has matured and been formalized as an ExternalObject, in
which all errors are integrated into the GraphQL response, preserving their initial path. Those
advanced users accessing the result directly will note the change in error handling. This also
allows for the deprecation of unnecessary helper functions including slicedError, getErrors,
getErrorsByPathSegment functions. Only external errors with missing or invalid paths must
still be preserved by annotating the remote object with special properties. The new
getUnpathedErrors function is therefore necessary for retrieving only these errors. Note also
the new annotateExternalObject and mergeExternalObjects functions, as well as the renaming
of handleResult to resolveExternalValue.
Transform types and the applySchemaTransforms are now relocated to the delegate package;
applyRequestTransforms/applyResultTransforms functions have been deprecated, however, as
this functionality has been replaced since v6 by the Transformer abstraction.
The transformRequest/transformResult methods are now provided additional delegationContext
and transformationContext arguments -- these were introduced in v6, but previously optional.
The transformSchema method may wish to create additional delegating resolvers and so it is now
provided the subschemaConfig and final (non-executable) transformedSchema parameters. As in
v6, the transformSchema is kicked off once to produce the non-executable version, and then, if
a wrapping schema is being generated, proxying resolvers are created with access to the
(non-executable) initial result. In v7, the individual transformSchema methods also get access
to the result of the first run, if necessary, they can create additional wrapping schema
proxying resolvers.
applySchemaTransforms parameters have been updated to match and support the transformSchema
parameters above.
wrapSchema, makeRemoteExecutableSchema, and @graphql-tools/wrap)wrapSchema and generateProxyingResolvers now only take a single options argument with named
properties of type SubschemaConfig. The previously possible shorthand version with first
argument consisting of a GraphQLSchema and second argument representing the transforms should
be reworked as a SubschemaConfig object.
Similarly, the ICreateProxyingResolverOptions interface that provides the options for the
createProxyingResolver property of SubschemaConfig options has been adjusted. The schema
property previously could be set to a GraphQLSchema or a SubschemaConfig object. This
property has been removed in favor of a subschemaConfig property that will always be a
SubschemaConfig object. The transforms property has been removed; transforms should be
included within the SubschemaConfig object.`
The format of the wrapping schema has solidified. All non-root fields are expected to use
identical resolvers, either defaultMergedResolver or a custom equivalent, with root fields
doing the hard work of proxying. Support for custom merged resolvers throught
createMergedResolver has been deprecated, as custom merging resolvers conflicts when using
stitching's type merging, where resolvers are expected to be identical across subschemas.
The WrapFields transform's wrappingResolver option has been removed, as this complicates
multiple wrapping layers, as well as planned functionality to wrap subscription root fields in
potentially multiple layers, as the wrapping resolvers may be different in different layers.
Modifying resolvers can still be performed by use of an additional transform such as
TransformRootFields or TransformObjectFields.
The ExtendSchema transform has been removed, as it is conceptually simpler just to use
stitchSchemas with one subschema.
The ReplaceFieldsWithFragment, AddFragmentsByField, AddSelectionSetsByField, and
AddMergedTypeSelectionSets transforms has been removed, as they are superseded by the
AddSelectionSets and VisitSelectionSets transforms. The AddSelectionSets purposely takes
parsed SDL rather than strings, to nudge end users to parse these strings at build time (when
possible), rather than at runtime. Parsing of selection set strings can be performed using the
parseSelectionSet function from @graphql-tools/utils.
stitchSchemas & @graphql-tools/stitch)stitchSchemas's mergeTypes option is now true by default! This causes the onTypeConflict
option to be ignored by default. To use onTypeConflict to select a specific type instead of
simply merging, simply set mergeTypes to false.
schemas argument has been deprecated, use subschemas, typeDefs, or types, depending on
what you are stitching.
When using batch delegation in type merging, the argsFromKeys function is now set only via the
argsFromKeys property. Previously, if argsFromKeys was absent, it could be read from args.
Support for fragment hints has been removed in favor of selection set hints.
stitchSchemas now processes all GraphQLSchema and SubschemaConfig subschema input into new
Subschema objects, handling schema config directives such aso@computed as well as generating
the final transformed schema, stored as the transformedSchema property, if transforms are
used. Signatures of the onTypeConflict, fieldConfigMerger, and inputFieldConfigMerger have
been updated to include metadata related to the original and transformed subschemas. Note the
property name change for onTypeConflict from schema to subschema.
addMocksToSchema and @graphql-tools/mock)args, context, and info
with parent available as this rather than as the first argument.@graphql-tools/utils)filterSchema's fieldFilter will now filter all fields across Object, Interface, and Input
types. For the previous Object-only behavior, switch to the objectFieldFilter option.fieldNodes utility functions have been removed.typeContainsSelectionSet function has been removed, and typesContainSelectionSet has
been moved to the stitch package.Operation type has been removed in favor of OperationTypeNode from upstream
graphql-js.applySchemaTransforms/applyRequestTransforms/applyResultTransforms have been
removed from the utils package, as they are implemented elsewhere or no longer necessary.