Graphback: Move resolver creation to plugins

[craicoverflow]

Original discussion is in https://github.com/aerogear/graphback/issues/1411

LayeredRuntimeResolverCreator creates the standars CRUD resolvers but is in no way scalable or extendable.

It makes sense to move resolver generation to the existing plugin system as it is easy for developers to extend Graphback in one place.

[craicoverflow]

We can extend GraphbackPlugin easily without making major changes to the plugin architecture.

The resolvers array can be a new property of GraphbackCoreMetadata.

export abstract class GraphbackPlugin {
    public transformSchema(metadata: GraphbackCoreMetadata): GraphQLSchema {
        return metadata.getSchema();
    }

    public createResolvers(metadata: GraphbackCoreMetadata): GraphbackResolvers {
      const resolvers: GraphbackResolvers = {
        Query: {
          hello: () => {
            return 'Hello World!'
          }
        }
      }

      return resolvers
    }
}

I think we should be opinionated with resolver format in plugins (choosing Apollo format) to prevent different plugins creating resolvers in multiple incompatible* formats.

I don't know if they are incompatible, what happens if you try to merge x and y resolvers, x being the Apollo format and y being in the GraphQL.js format?

[wtrocki]

hmm.. we should use graphql-tools everywhere - GraphQL-tools for schema creation will resolve format problem and document that to create schema you need to use graphql-tools.

Also - we should pass resolvers array to the method rather than create it itself.
The first plugin will get empty array.

[wtrocki]

I remember having discussion on this already. Anyway.. This is very pressing matter and worth to do it (considering it will be trivial copy paste change)

[craicoverflow]

Also - we should pass resolvers array to the method rather than create it itself.
The first plugin will get empty array.

I thought about this, but above approach would mean the plugin would have to do minimal amount (create its resolvers). Plugin engine would then add it to array.

[machi1990]

Also - we should pass resolvers array to the method rather than create it itself.
The first plugin will get empty array.

What happens if the array is modified by custom-malicious-plugin and delete others of the resolvers? I was thinking more of an approach where plugin creates resolvers and these are added to the list that's only accessible by the core.

[wtrocki]

Works for me!

[craicoverflow]

Agreed @machi1990 - plugin D should have no reason to access resolvers created by plugin A, B, C.

[craicoverflow]

Going to start this

[wtrocki]

+100. It is important to have this