composite-schemas-wg
composite-schemas-wg copied to clipboard
graphql
subschema composability rules
Comments welcome!
This is just an initial version, and has much room for improvement.
I have marked this PR as no longer DRAFT, as I have added section regarding all types. But it would certainly benefit from additional input and further revision. Comments are welcome.
This is a great doc! I don't find the GitHub PR interface great for reviewing Markdown, so I wrote up a few thoughts in the discussion thread: https://github.com/graphql/composite-schemas-wg/discussions/35#discussioncomment-3400447
Minor markdown styling comment: please use
`backticksForCode`
and
*italics for references*
i.e. change
`Subschemas as remote GraphQL services`
to
*Subschemas as remote GraphQL services*
This follows the pattern used by spec-md.
This follows the pattern used by spec-md.
@benjie any styling for definitions like for “composability” ?
@yaacovCR Indeed; if you're actually using spec-md then the paragraph that defines a term should start with :: and the term should be the first italicised term. Then references to it should use italics. Here's an example of request being defined in the spec:
https://github.com/graphql/graphql-spec/pull/949/files
During our call today we outlined where we're going, and sounds like composability rules are on the horizon again.
@michaelstaib @martijnwalraven We could use Yaacov's PR here as a discussion starter.
in the rfc there were several times mentioned ways to influence schema objects composability
a method of composition may be devised in which elements in different subschemas with different names are mapped to the same element in the composite schema via some set of guiding metadata.
As far as I understood, it must be some directives, which allow merging or do merging implicitly? May small paragraph on directives which supply merging will be useful there?
(please just ignore my input, if it doesn't help!)
