Web-based GraphQL IDEs for the win: How & Why Playground & GraphiQL are joining forces
GraphiQL’s beginnings
The initial public commit to GraphiQL was in 2014.
When Lee Byron,
Hyo Jeong and
Angel Gomez first published it, the intention was to
create a minimal reference IDE development ecosystem for GraphQL.
Greg Hurrell created the streaming
graphql-language-service-parser
, designed to empower the codemirror-graphql
mode.
The goal was to give people the utility packages they needed to build their own web based or desktop IDE tool, and at its core, a relatively simple tool for folks to start learning and applying the language, and for exploring schemas. At the time, LSP was not yet a commonly accepted standard, and VSCode had yet to become the incredibly popular development tool it is today.
Last year, these original engineers handed over to the graphql foundation three
repositories: GraphiQL, codemirror-graphql
and the graphql-language-service
packages.
Fast forward to now, and GraphiQL is now used by GraphQL implementations in dozens of languages, as well as hundreds of frameworks and runtimes. It’s used for everything from HTTP operations, to querying local schemas, data science tools, and even for data transmission for IOT platforms. You’ll find it in the AWS dashboard, GitHub developer tools, and many more places we are honored to see this library used.
Enter Playground
Alongside GraphiQL, many of us are familiar with its sibling - the handsome &
feature-full
GraphQL Playground.
Following GraphiQL’s lead, it uses our codemirror-graphql
(Insomnia,
Altair and many others are also in this
club!). This is why there are so many similarities between the direct editing
experience of these tools.
Playground is exactly what we wanted to happen. It helped drive the
development of our language ecosystem, and gave users an easier option than the
more customization-oriented GraphiQL. It provided a ton of excellent features -
graphql-config
support, multiple tabs, i18n, and http server middlewares.
Prisma Donates Playground to GraphQL Foundation
As many have successfully guessed, Prisma is donating Playground to the GraphQL Foundation. Entering 2019 Prisma envisioned an eventual Playground 2.0 but then the advent of a modular GraphiQL 2 project showed an opportunity for great synergy, made all the more natural by Prisma’s pivot toward modular database tooling for developers.
Playground 1.x has been a community effort of dozens of contributors. Prisma thanks all contributors who helped out along the way. Prisma remains deeply committed to supporting the future of the GraphQL language. For example the Prisma Labs team continues to focus on GraphQL API layer and recently announced the transition of Nexus from a schema building library into a full fledged GraphQL API framework.
The Playground Features you love
In the interest of parity, we will keep a lot of the same features, whether by introducing them to the core or proving plugins that will ship with the playground preset.
- multiple tabs (GraphiQL Core)
- headers tab per operation tab (plugin)
- tracing tab (plugin)
- playground doc explorer (plugin)
- internationalization (GraphiQL Core)
graphql-config
support, with new features thanks to our fantastic colleagues at the Guild Dev, who Prisma has entrusted with many other projects.- easy to use middlewares
New Features
These new features will come with the new graphql@2.0.0
:
- vscode style command palette (via
monaco-editor
) - jump to fragment or other type definitions
- generate a collection of operations from your project’s source files
- more customizable network options - default headers per project, as well as headers per-operation
- helpers for integrating custom authentication flows
- extensive theme, layout, and component customization abilities (you can start with the playground theme preset and work from there!)
- custom tabs and panels
- a first-class
graphiql-explorer
plugin in partnership with the original creators, our colleagues at OneGraph
How will it be re-implemented?
Playground 2.0 will be a GraphiQL preset that includes the custom theme as well as the custom playground doc explorer plugin (as an alternative to the new doc explorer proposed by @orta and other users), HTTP headers and tracing tab plugins. You can find more technical detail, ongoing discussion and things to work on the GraphiQL Plugin API Meta Issue or in other playground related discussion issues in the GraphiQL monorepo.
While the Playground team’s baseline goal will be relative parity with Playground 1.0, the team will be accepting proposals for new features and plugins that build on the existing GraphQL Playground experience. The Features Roundup project is a great place to see what we have planned already for plugins that Playground’s preset can use, or you can also create a proposal if you don’t see what you’re looking for.
graphql-playground
repository next steps
The existing graphql-playground
repository will get one or two more
maintenance/bugfix releases before it will be archived. You can still fork it of
course. You can learn more about this in
the graphql-playground issue
we created for this migration.
Call for Contributors
We’re also looking for contributors to form a team to develop, support and maintain a playground preset. The goal would be for them to help iterate on and stabilize the plugin API effort, as well as work towards the effort of contributing to and maintaining the playground preset and its associated plugins. If you are interested leave comment in the Call for Contributors Github issue.
You can also follow the Plugin API Proposal discussion issue for updates, and get involved in our discord channel we’ve created just for the playground initiative.