Add callout that external subschema approach is not prohibited. #19
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm overall not convinced that the way the specification is designed should match how it is used. Most teams/groups using composition may be "in control" of all of the different subchemas/source schemas, but I'm not convinced that this definitely so; perhaps they are "in control" of most of them but want to link to popular 3rd party APIs, Github/Stripe, etc. Since the problem of connecting arbitrary subschemas is a superset of what the specification currently proposes, I think it would make sense to start there, as otherwise the specialized case crowds out the more general.
So I would be in favor of a more generic specification that describes how multiple GraphQL schemas can be composed, and then leave room for additional tooling that might be helpful for those teams that are truly "in control" of all of their subschemas, and am leaning against the vision suggested here.
On the other hand, this PR introduces a small change that just highlights that it should be possible to transform arbitrary schemas into compliant source schemas, which I think might bridge the overall gap.