🧘 Rewrite of a fully-featured GraphQL Server with focus on easy setup, performance & great developer experience. The core of Yoga implements WHATWG Fetch API and can run/deploy on any JS environment.
The progress of version 3 is tracked on branch v3. Canary releases will be released from that branch. Once the branch becomes stable it will be merged into master and we will release the stable version 3 to npm.
### Reasons to do that
- To improve Conductor execution and performance through Mesh
- Remote executor and avoid wrapping a clean executor function
- To remove the coupling to specific GraphQL schema implementation (resolvers)
- Any other alternative executing strategies that don't follow the default GraphQL-JS execution algorithm
- Resolvers are just one way of implementing the schema, some execution engines might not use it (Benjie’s stuff, GraphQL-Tools executor, Federation)
### Technical Path
1. Drop `onResolverCalled` from `envelop` API
2. Drop `onSchemaChange` , `setSchema` APIs
1. @ardatan should this be `onExecuteFnChnage` instead? some plugins like `useExtendedValidation` might need to things like build `TypeInfo` (and we wish to make sure it happens once, because of performance)
2. Should we introduce an alternative Envelop API for wrapping the `execute` function?
3. Make sure all plugins that needs access to the schema implements the schema access through `execute` function arguments (this should be the recommended way of dealing with the schema)
At The Guild we’ve decided to work as much as we can in public, that’s why we are opening the roadmaps for all of our projects.
The goals for this are:
v3 - Released!
The progress of version 3 is tracked on branch
v3
. Canary releases will be released from that branch. Once the branch becomes stable it will be merged intomaster
and we will release the stable version 3 to npm.v3.x
graphql-yoga@three
graphqlEndpoint
live
RFC on the repoThings that might go into v3:
Making Envelop Schema Agnostic