benjie
commented
7 months ago I somewhat agree that the term "composite schema" is too broad for the narrow focus of this spec which relies on collaboration and distributed execution among the schemas. The "preserve option value" guiding principle suggests it might be worth finding a term that leaves space for us to tackle this larger problem of building a composite of arbitrary schemas in a future effort.
A bit wordy, but perhaps "collaborative schema composition" or "distributed schema composition" correctly captures the effort?
"Distributed schemas" also works quite well with what's currently being proposed because each underlying schema relies on information from the dispatcher in order to execute properly. In the current proposal, the underlying source schemas cannot execute all their fields on their own, they are dependent on data passed to them from the dispatcher (data fetched from other source schemas) in order to populate the field correctly, and the dispatcher in turn is dependent on the underlying schemas to know what composite schema to build.
smyrick
When we revived this standardization effort, we retained the composite schemas name both for the WG and spec. Given our current focus however, it seems to me that naming doesn't really do justice to our goals and may set the wrong expectations.
Take the first paragraph from the Overview section:
By only describing the process in terms of composing schemas, we leave out the important fact that the goal of the spec is to enable distributed execution across a set of GraphQL services. If we were just talking about composing a set of schemas locally, we'd be in a very different design space (e.g. we wouldn't have to worry about crossing service boundaries, defining entity keys, etc.).
Although distributed execution is mentioned as a point of focus at the end of the Overview section, I think we should be explicit about this from the start. And I would even say the design principles go beyond just distributed execution, and are formulated with a federated architecture in mind (e.g. by calling out team collaboration and associated workflows).
So I wonder if the name of the spec shouldn't reflect this. Although a spec isn't necessarily meant for end users, picking a more meaningful name would help users understand compatibility claims. Since the term federation is well known by now and in use by multiple vendors, calling the spec something like GraphQL Federation may be worth considering.