Plugin: ForceResolver

[mathewbyrne]

This is a first attempt to chip away at progressing a plugin system from #228. This implements a single plugin resolver that adds a directive @resolver to the schema, and allows a user to tag fields in their schema as requiring a resolver; this is the same functionality exposed in config.

Plugins

After a bit of discussion in #228 and elsewhere, our initial direction for supporting plugins will be to ship the gqlgen binary with a set of base plugins, and let users generate their own binary if they want to add additional plugins themselves.

We considered some other directions, such as using the plugin package — but have decided to keep it simple while we're actually developing the capabilities of the system. Feedback is welcome here as to how this will fit into your existing workflows.

Registration

Plugins are registered via codegen.RegisterPlugin and should satisfy codegen.Plugin. It is currently expected that this would be done in a plugin package's init function.

Hooks

This PR adds 2 ways that plugins can hook into codegen functionality:

1. Plugin.Schema should return an *ast.Source (perhaps should be []*ast.Source?). These will be merged with the user's schema during parsing, allowing a plugin to add to a schema as it sees fit. Since this occurs before parsing, it may be too limiting for some plugin use-cases. We're investigating whether we need to separate out the parsing and validation steps in the parser.

2. Plugin.Execute is called after config normalization, and allows a plugin to arbitrarily modify configuration prior to codegen.

These two hooks are sufficient for the resolver plugin to function, but we definitely understand that there will be lots of other use-cases that require additional hooks. My plan with this PR is to validate this general approach, and understand how we could expand (or even limit) it towards additional plugin use-cases.

[vektah]

I wonder if this should be done by the caller and this function can just return the schema string?

[vektah]

if d == nil { continue }?

[vektah]

Do we want one large interface with lots of methods or lots of small interfaces that can optionally be implemented?

eg we may eventually have codegen hooks here, but most plugins wont use them.

[vetcher]

lots of 1-function interfaces will be easier to use, then one big.

[vetcher]

As I understand, in this realization, I need to rebuild gen every time I add new plugin?

[vektah]

@vetcher theres a few different fronts that can be advanced here but its tricky. Right now, we are focusing on what the plugins can do rather then how they get injected.

We've thought a little about using go plugins (and probably will support it in the future) but it adds a bunch of complexity:

• easiest implementation is to only support .so files, but that puts burden on the user
• tricker implementation lets the user pass in random go paths and the code gets fetched, built and injected
• windows isnt supported at all currently by the go plugin system (plugin: add Windows support golang/go#19282)
• theres also https://github.com/hashicorp/go-plugin using a client server architecture

For now we are just going to side step that complexity by building a bunch of plugins into the binary, and making it easy to build your own entry point.

fun fact, gorunpkg github.com/99designs/gqlgen is already building gen on demand from source.

[vetcher]

@vektah you may add a line to config, name it plugins and, on start up, just open list of files and do nothing with them. Something like that.

func initPlugins(plugins []string) error {
	for i := range plugins {
		_, err := plugin.Open(plugins[i])
		if err != nil {
			return errors.Wrapf(err, "open plugin %s", plugins[i])
		}
	}
	return nil
}

And in plugin we just need to add 3 lines:

func init() {
	codegen.RegisterPlugin(plugin)
}

It can be nice addition to current realisation and user does not need to recompile gqlgen each time.

[mathewbyrne]

@vetcher this PR is really more about exposing functionality for plugins to hook into. We definitely will consider plugin distribution carefully once we have a better idea how they will integrate. Feel free to move this sort of discussion into #228

[mathewbyrne]

@vektah ok I've had another pass over this now. Key changes:

1. Multiple interfaces for a plugin to define what functionality they want to support.
2. Changed plugin schema interface to just return a string.
3. Updated parsedSchema in generated output to add plugin schemas (removed SchemaRaw)
4. Inject plugins through config in gen and init commands.

[mathewbyrne]

Maybe resolver is too generic a plugin name; this clashed so I changed the resolver struct name here.

[mathewbyrne]

For context — I've closed this for now. We're thinking about doing a plugin release the one after next and focussing on it entirely. This has been around long enough now though that our thinking has shifted a little and we might approach this slightly differently.