Graphql-playground: Plugin Architecture

[schickling]

GraphQL Playground is turning more and more into a GraphQL development platform (similar to VSCode). To better handle the increasing demand for customization and new features, I suggest introducing a plugin system to GraphQL Playground.

Goals

Inspiration: https://code.visualstudio.com/docs/editor/extension-gallery

• Discoverability
• Easy to write plugins
• Easy to install plugins
• Compatibility

Plugins

Existing functionality that should be rewritten as plugins or ideas for new plugins

• Sharing via GraphQL Bin
• Color themes
• Custom authentication (SSO)
• HTTP Proxy
• Apollo Tracing #241

Open Questions

• [ ] Terminology: Plugin vs extension vs package
• [ ] How do plugins fit into the web-based version of the GraphQL Playground (Suggestion: Some plugins are built-in, other than that, plugins are just available for the desktop version)
• [ ] Plugin configuration #234

[n1ru4l]

Maybe apollo-link could be a very helpful part of the plugin architecture 🤔. Each plugin could provide its link and graphql-playground could compose those.

E.g. The "tracing-extractor-link" (https://github.com/n1ru4l/graphiql-apollo-tracing/blob/master/src/tracing-link.js) extracts the tracing information from the payload and notifies listeners with that data.

Related #195

[huv1k]

I would like to work on it, do we want have plugins similar to hyper? Or more to vscode?

[jbhoosreddy]

We're planning on using GraphQL for an internal debugging service. One of the ideas (@mheiber) is to have shareable codepens, and a list of most recent pens, and pin named pens in the UI. A plugin architecture would really help here.

@schickling Is there a plan for doing this work in the horizon? We're discussing whether we have to fork our own version or push things upstream if maintainers are open to PR.
Edit: I see it's in 2.0 milestone so that's probably a good sign. Would be great to know a timeline. Thanks.