Comments (3)
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.
from composite-schemas-spec.
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.
from composite-schemas-spec.
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.
from composite-schemas-spec.
Related Issues (11)
- Should entity resolvers be limited to the root level. HOT 1
- Better terms for supergraph, subgraph and public API needed. HOT 12
- Can we come up with a better term for `@entityResolver` / `@finder`? HOT 4
- What term should we use for a federated gateway / router in this specification? HOT 14
- More GraphQL native expression for FieldSelection? HOT 9
- Terminology: gateway v.s. distributed executor HOT 2
- Composite Schemas vs. Distributed/Federated HOT 2
- Finding the right Batching Mechanism HOT 6
- Finding the right Batching protocol HOT 1
- Discuss the effect on public schema of `@internal` directive HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from composite-schemas-spec.