Stitching or Merging with Yoga v3

[alexanderniebuhr]

We are currently preparing to migrate to Yoga v3.
We do have a rather large private schema which was seperated into multiple files and then merged before. We wonder if we should stay with merging or introduce schema stitches. Server runs on a container instance with multiple regions on multiple clouds, no remote-schema for now.

We can divide the schema by scope, User / Content / Data / ...
Any advice for us to evaluate if we should merge the schema or stitch it?

[ardatan]

If you don't have any remote schemas, you can use merging or GraphQL Modules;
https://graphql-modules.com/

[alexanderniebuhr]

Ok so it is recommended to stay with merging, because the possible benefit of stitching is not worth the complexity for local schemas only?

[ardatan]

Schema stitching (@graphql-tools/stitch) creates a single GraphQL gateway schema from multiple underlying GraphQL services. Unlike schema merging, which simply combines local schema instances, stitching builds a combined proxy layer that delegates requests through to underlying service APIs. As of GraphQL Tools v7, stitching is fairly comparable to Apollo Federation with automated query planning, merged types, and declarative schema directives.

Note that schema stitching is a superset of the schema wrapping API. Rather than wrapping schemas individually and then combining them, stitchSchemas may be used directly to handle all wrapping concerns.

Taken from the docs. so stitching is more like to manipulate remote schemas. Even if your local schema is complex, I'd suggest merging or its superset GraphQL Modules.