graphprotocol / mutations

Apache License 2.0
4 stars 5 forks source link

Apollo Agnostic Execution #11

Closed dOrgJelli closed 4 years ago

dOrgJelli commented 4 years ago

In order to make the @graphprotocol/mutations package completely Apollo agnostic, we must:

With the above complete, we can also remove the requirement for the @client directive on all mutation queries.

Related: https://github.com/graphprotocol/mutations/issues/2 & https://github.com/graphprotocol/mutations/issues/3

Jannis commented 4 years ago

An easy way to get the mutations schema into createMutations would be to require mutations to export not just

export default {
  resolvers,
  config
}

but

export default {
  resolvers,
  config,
  schema
}

where schema would be a parsed GraphQL schema document. It feels a little redundant since the schema is also included in the manifest, but it may be the only way.

(The only other way I can think of right now would be to allow to import the manifest YAML into code that consumes the mutations (would require a custom babel/webpack/typescript loader) and then get to the schema file somehow. Not great.)

Jannis commented 4 years ago

What createMutations would then do is take that schema and the resolvers, wrap the resolvers like we do know and inject them into the schema. In pseudo-code:

for mutationField in schema:
  mutationField.resolver = wrappedResolver[mutationField.name]

Query execution inside the @graphprotocol/mutations package would then call https://graphql.org/graphql-js/execution/#execute with the schema that has the injected resolvers.

I think that ought to work. Obviously, I haven't tested it myself.

Jannis commented 4 years ago

This is the part that needs to be replaced with that execute() call: https://github.com/graphprotocol/mutations/blob/f0f500c9d174acca10afb928861413e3f6f72bbf/packages/mutations/src/executors/mutation/localResolver.ts#L37-L48

dOrgJelli commented 4 years ago

This is great, thanks so much for piecing this all together @Jannis :pray:

Almost finished with the implementation, just writing some logic for handling parallel mutations in a single query.

Additionally, I'm thinking that it'd be best to export the schema from the mutations module as a string. This way we don't require the resolver developer to import and parse the graphql schema themselves, and only need to include it as raw text in their bundle. The graph-cli can buildSchema and ensure it's valid for the resolver developer. Exporting as a string makes validation in graph-cli easier IMO. Your thoughts @Jannis @namesty ?