Do we agree execution mechanisms are out of scope for this specification?

[martijnwalraven]

The draft specification in this repository currently refers explicitly to the use of query plans to implement execution:

This specification describes the process of composing a federated GraphQL schema and outlines algorithms for executing GraphQL queries on the federated schema effectively by using query plans.

And:

A distributed GraphQL executor acts as an orchestrator that uses schema metadata to rewrite a GraphQL request into a query plan.

I think we agreed in previous meetings that execution mechanisms would be out of scope for this specification. So my proposal would be to add a note like:

The exact mechanisms of execution are outside the scope of this specification. Typically, implementations rely on a query planning phase to generate a query plan that describes the orchestrated execution of one or more requests to subgraphs that together satisfy a particular operation. Implementations are free to implement execution as they see fit however, and we expect this to be an area of continued innovation.

[michaelstaib]

I think we agreed in previous meetings that execution mechanisms would be out of scope for this specification. So my proposal would be to add a note like:

Not really, we said we do not focus on it initially but will later revisit this. I personally think the execution should be part of the spec... but it would not need to be a query plan based one or whatever ... but for people implementing it, it should provide a good starting point like the GraphQL core spec is. The GraphQL core spec describes execution algorithm that describe how the observable result can be created but explicitly calls out that no one has to follow it as long as the observable result is the same.

I think for testability and getting started we should provide algorithms for this.

[michaelstaib]

But we can put this in:

The exact mechanisms of execution are outside the scope of this specification. Typically, implementations rely on a query planning phase to generate a query plan that describes the orchestrated execution of one or more requests to subgraphs that together satisfy a particular operation. Implementations are free to implement execution as they see fit however, and we expect this to be an area of continued innovation.

[martijnwalraven]

I personally think the execution should be part of the spec... but it would not need to be a query plan based one or whatever ... but for people implementing it, it should provide a good starting point like the GraphQL core spec is.

There is a close relationship between 'satisfiability' of a composed schema and execution, because the former guarantees that there is always at least one possible 'query path' for each field. Not sure how that translates to a usable algorithm yet, but we can definitely revisit it. Just want to make sure we focus on observable results and don't overspecify implementation.