Graphback: Cannot use sync from DataSync

[ssd71]

On trying the 'sync' query:

Please use DataSync provider for delta queries

It seems the sync resolver is not actually returning anything:
https://github.com/aerogear/graphback/blob/b7c74ed0515d9e3e1771cbf9cb8db47732ddb98c/packages/graphback-runtime/src/resolvers/LayeredRuntimeResolverCreator.ts#L89-L100

Was this removed to discuss further ways of adding this resolver outside of @graphback/runtime :thinking: ?

I think this is a good opportunity regardless, do let me know what you think :)

[ssd71]

CC @craicoverflow

[wtrocki]

Yep. We need to have chat about this
Generally it is pointless for us to have separate package with datastore if we have embedded DataSync in resolvers.

We can bring sync resolvers here.
Figure out how to add them separately
Decide that all stuff is deeply integrated and part of the graphback - so no DataSync package

[ssd71]

I was thinking if it would be useful to be able to add resolvers from a plugin (or something similar).
In current state the plugins can only modify the schema, leaving graphback to fill in the gaps, therefore there is not much point to other people building plugins if they cannot do anything other than modify schema without adding any extra resolvers. Correct me if I am wrong, if plugins can add more resolvers, doesn't that also mean we could add custom scalars with a plugin?

Sounds overkill I guess but just wanted to discuss ways of working around this, this seems generic and somewhat functionally beneficial, but also since this concerns graphback-core, this has become a kind of a circlejerk. Overall, this is just an opinion: I think plugins are very separate from graphback and are quite limited in what they can do :thinking:

What do you think? Please let me know if this is redundant stuff :smile:

[wtrocki]

You are right. We kinda need that. Previously we had plugins generate files that could be resolvers now we have this runtime resolver creator that do not have it

[craicoverflow]

It seems the sync resolver is not actually returning anything:

That was a mistake by me, when merging conflicts! Sorry about that.

[ssd71]

It seems the sync resolver is not actually returning anything:

That was a mistake by me, when merging conflicts! Sorry about that.

Ah cool :smile: , though what do you think about the rest of the discussion above

[craicoverflow]

I do believe we need some form of plugin for resolvers. I was originally thinking this might require a new plugin engine specifically for resolvers, but it should work just fine in the regular plugins.

GraphQLSchema object can contain all resolver methods. I've just tested the following example in SchemaCRUDPlugin and it works.

schemaComposer.addResolveMethods({
  Query: {
    hello: (source: any, args: object, context: unknown, info: any) => {
      return 'Hello world!'
    }
  }
})

const resolvers = schemaComposer.getResolveMethods()

This could actually be a much more centralised/extensible approach to building the Graphback API - and nothing architecture-wise has to change!

Currently we return typeDefs and schema - but schema does not have resolver methods, only type definitions so it is pretty much useless.

[wtrocki]

I put some thoughts and I think extending current plugin format will be rather simple and effortless.

What we need is plugin to add or edit resolvers object directly - it will mean that schema plugin will need to take all the responsibility of the LayeredRuntimeResolverCreator which was artificially put into runtime package.

Then datasync plugin will simply add extra stuff. LayeredRuntimeResolverGenerator is an.. legacy historical reason because of the codegen approach we had.

I can explain more if needed.
WDYT?

[wtrocki]

We probably looking to add new method into abstract plugin:

abstract addResolvers(resolverObject: any){
    return resolverObject;
}

[craicoverflow]

We probably looking to add new method into abstract plugin:

abstract addResolvers(resolverObject: any){
  return resolverObject;
}

No need IMO - Resolvers can be added to schema object and separated at any point outside the plugin.

[craicoverflow]

I'm going to spin a new issue from this about resolver generation in plugins.