Plugin System

[mathewbyrne]

As a part of furthering our support of directives, we would like to provide a system in the gqlgen binary to allow user and 3rd party code to interact with codegen. Some of the use-cases we are considering include:

• Allowing a directive to generate a resolver for a field — e.g. rest/grpc calls.
• Allowing directive definitions and types to a schema.
• Altering a schema prior to codegen — e.g. enabling easy Relay connections.

The current plan is a plugin system which exposes a mechanism for allowing external plugins or code to register to be notified at various points during gqlgen's execution, and modify the schema and codegen configuration.

These plugins are probably loaded and configured through the existing configuration file. The plugins will probably be provided with the schema AST, and configuration that can be modified as required.

We're looking to start building this soon, but would welcome any additional use-cases for consideration.

[ermik]

There should be a generic 'middleware' plugin for things beyond OpenTracing to patch in to request/response and resolution logic. E.g. sometimes it is important to know exactly how long unmarshall/marshall took and I imagine there would be endless contenders in that space.

I use go-kit so GraphQL lands as one of the transports hooking into the endpoints using the instance of Endpoints I passed the gql server during instantiation. Not necessarily a plugin issue, but I see how codegen for go-kit may want to take over from your process to create Endpoints and Service according to their idioms. (Codegen talking to codegen, isn't that awesome?!)

[vektah]

I think that already exists @ermik Did you see https://github.com/99designs/gqlgen/tree/master/opentracing and the example use in https://github.com/99designs/gqlgen/blob/master/example/dataloader/server/server.go?

[ermik]

I saw it, hence the change in the wording of my comment. It's one middleware. If you fully support middleware pattern at a 'plugin' level I think there would be more pluggability (is that a real word?) without much additional development needed.

I do understand though @mathewbyrne meant "schema-transformers" when he said "plugins". I think that's just one type of plugin.

[dannymidnight]

+1 for plugins.

It would be great to have some contrib plugins for common directives e.g. form input validation https://www.npmjs.com/package/graphql-constraint-directive

[mathewbyrne]

@dannymidnight something like that could already be achieved with the existing field directives; but good point though, my current thinking around this feature hasn't included making field directives pluggable. We should include a solution for that too in this plan.

[vetcher]

I see here 3 variants (or any combinations):

1. take approach from protoc: plugins is an executable, transport via stdin
2. use golang (plugin)[http://golang.org/pkg/plugin] package: define interface some interface, with will be used to call plugins from imported .so files
3. some template engine, e.g. default text/template: templates will override existing parts of code (functions/files?) or adds their own

I was thinking about same extention system for my codegen and may help with realization

[mathewbyrne]

take approach from protoc: plugins is an executable, transport via stdin

We did discuss this briefly, but we're not super keen on transport like that. It adds a lot of complexity in coming up with a protocol, loses type safety etc. It has the benefit of being easy to distribute.

use golang (plugin)

This we were interested in, but loses Windows support. It still could be the way we head, but we need an option for Windows users, which has lead us to the initial implementation in #354

some template engine

Im not sure exactly what you mean here, but my guess it that you're suggesting the codegen load additional templates. This probably doesn't give us enough flexibility as we want plugins to be able to introspect parsed schemas and configurations and make changes based on that.

[sdalezman]

Would you be able to utilize the plugin system for schema stitching? That to me would really be a killer feature and would allow us to build a lot of really great features on top of gqlgen

[steebchen]

• Altering a schema prior to codegen — e.g. enabling easy Relay connections.

Plugins would be awesome just for this reason. Of course pagination can be simply built by people themselves, but I believe that almost everybody uses Relay connections in their GraphQL server, so it would be powerful to have this built-in.

[mskrip]

Our usecase would be that we want to add custom tags to fields that are being generated with modelgen. Current implementation of modelgen straight out renders the template right after mutating the config. It would be nice to be able to chain multiple model-generating plugins (altering generated models before actually rendering them).

The way to do it now to just copy and paste the whole modelgen plugin and change one line in it (the tag).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

No stale.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

No stale.

[GiancarlosIO]

👀

[quinn]

any updates here? i'm interested in this for creating something for Relay. I see the WIP PR was closed, any way for someone to contribute to this?

[everdrone]

Any updates? Is there anything we can do to support this?

[listepo]

any news?