Announcing: Playground 🤝 GraphiQL, Retiring Playground #1143
Labels
Comments
jasonkuhrt
changed the title
|
anyone who wants to help with security and bugfixes today, you can find me on our discord channel for playground: https://discord.gg/8RQK2F, I'm about to introduce a PR that re-introduces yarn workspaces to make the security fixes, because it was causing an issue where tons of yarn.lock entries could only be removed manually, it would seem? without just deleting and re-writing the lockfile again. and when i tried deleting the lockfile, the sub-package dependencies didn't install :/ any reviews on my or other bugfix/security PRs today would be super helpful, regardless of whether your review is an official approval or not. |
|
The Discord invites in your posts have expired. @acao @jasonkuhrt |
|
@oliversalzburg https://github.com/graphql/graphql-playground#help--community- links to discord, hopefully up-to-date |
|
hey thanks! been looking for where i need to fix this broken discord link |
|
fixed the discord link, sorry folks. so many links to maintain, lol |
7 tasks
acao
changed the title
glasser
added a commit
to apollographql/apollo-server
that referenced
this issue
May 11, 2021
Apollo Server has graphql-playground built in, to the degree that the playground-html renderPlaygroundPage options are a top-level key in Apollo Server config. This has been very useful, but the theme of Apollo Server 3 is to keep its API lean and disentangled from other packages. Every single Apollo Server integration package has the same copy-and-paste code that threads playground options directly into the playground package. Additionally, graphql-playground has is retiring (see graphql/graphql-playground#1143) and merging back into GraphiQL. So it especially doesn't make sense for Apollo Server's API to continue to be defined by Playground. We could just switch back to GraphiQL like in Apollo Server 1, but instead, let's move UI configuration out of the top-level ApolloServer API and move it into our plugin system. And let's make sure that the per-web-framework integration packages don't need to care what UI system you're using. This PR adds a very very very simple static HTML serving API to our plugin system. The point of this system is to support plugins that serve a bit of HTML to load a full UI from CDN, like for Playground, GraphiQL, Explorer, etc, or to serve a splash page linking to other UIs. The point of this system is not to be a convenient way to add app-specific HTML to your app. If you want to do that, just use middleware in your web framework! The point is to make UI plugins that work out of the box with every Apollo Server integration. Because of that, the plugins can do very little: they can serve static HTML pages at one or more URL paths, and they can ask for a redirect from root to one of their pages. We add ApolloServerPluginUIGraphQLPlayground in core, as well as ApolloServerPluginUIDisabled. Like other plugins, if you don't set some UI plugin of your own and don't set the disabled plugin, Apollo Server will auto-install a plugin. In this case it installs the playground plugin though we may change that before 3.0.0. Also: - Tests that set environment variables (as some of the playground ones do) make me uncomfortable. Added `__testing__nodeEnv` to the ApolloServer and GraphQLOptions interfaces that can be used to test how `process.env.NODE_ENV` affects AS without actually changing the environment. - Inline fastifyApollo into fastify's ApolloServer.
glasser
added a commit
to apollographql/apollo-server
that referenced
this issue
May 13, 2021
Apollo Server has graphql-playground built in, to the degree that the playground-html renderPlaygroundPage options are a top-level key in Apollo Server config. This has been very useful, but the theme of Apollo Server 3 is to keep its API lean and disentangled from other packages. Every single Apollo Server integration package has the same copy-and-paste code that threads playground options directly into the playground package. Additionally, graphql-playground has is retiring (see graphql/graphql-playground#1143) and merging back into GraphiQL. So it especially doesn't make sense for Apollo Server's API to continue to be defined by Playground. We could just switch back to GraphiQL like in Apollo Server 1, but instead, let's move UI configuration out of the top-level ApolloServer API and move it into our plugin system. And let's make sure that the per-web-framework integration packages don't need to care what UI system you're using. This PR adds a very very very simple static HTML serving API to our plugin system. The point of this system is to support plugins that serve a bit of HTML to load a full UI from CDN, like for Playground, GraphiQL, Explorer, etc, or to serve a splash page linking to other UIs. The point of this system is not to be a convenient way to add app-specific HTML to your app. If you want to do that, just use middleware in your web framework! The point is to make UI plugins that work out of the box with every Apollo Server integration. Because of that, the plugins can do very little: they can serve static HTML pages at one or more URL paths, and they can ask for a redirect from root to one of their pages. We add ApolloServerPluginUIGraphQLPlayground in core, as well as ApolloServerPluginUIDisabled. Like other plugins, if you don't set some UI plugin of your own and don't set the disabled plugin, Apollo Server will auto-install a plugin. In this case it installs the playground plugin though we may change that before 3.0.0. Also: - Tests that set environment variables (as some of the playground ones do) make me uncomfortable. Added `__testing__nodeEnv` to the ApolloServer and GraphQLOptions interfaces that can be used to test how `process.env.NODE_ENV` affects AS without actually changing the environment. - Inline fastifyApollo into fastify's ApolloServer.
glasser
added a commit
to apollographql/apollo-server
that referenced
this issue
May 24, 2021
Apollo Server has graphql-playground built in, to the degree that the playground-html renderPlaygroundPage options are a top-level key in Apollo Server config. This has been very useful, but the theme of Apollo Server 3 is to keep its API lean and disentangled from other packages. Every single Apollo Server integration package has the same copy-and-paste code that threads playground options directly into the playground package. Additionally, graphql-playground has is retiring (see graphql/graphql-playground#1143) and merging back into GraphiQL. So it especially doesn't make sense for Apollo Server's API to continue to be defined by Playground. We could just switch back to GraphiQL like in Apollo Server 1, but instead, let's move UI configuration out of the top-level ApolloServer API and move it into our plugin system. And let's make sure that the per-web-framework integration packages don't need to care what UI system you're using. This PR adds a very very very simple static HTML serving API to our plugin system. The point of this system is to support plugins that serve a bit of HTML to load a full UI from CDN, like for Playground, GraphiQL, Explorer, etc, or to serve a splash page linking to other UIs. The point of this system is not to be a convenient way to add app-specific HTML to your app. If you want to do that, just use middleware in your web framework! The point is to make UI plugins that work out of the box with every Apollo Server integration. Because of that, the plugins can do very little: they can serve static HTML pages at one or more URL paths, and they can ask for a redirect from root to one of their pages. We add ApolloServerPluginUIGraphQLPlayground in core, as well as ApolloServerPluginUIDisabled. Like other plugins, if you don't set some UI plugin of your own and don't set the disabled plugin, Apollo Server will auto-install a plugin. In this case it installs the playground plugin though we may change that before 3.0.0. Also: - Tests that set environment variables (as some of the playground ones do) make me uncomfortable. Added `__testing__nodeEnv` to the ApolloServer and GraphQLOptions interfaces that can be used to test how `process.env.NODE_ENV` affects AS without actually changing the environment. - Inline fastifyApollo into fastify's ApolloServer.
glasser
added a commit
to apollographql/apollo-server
that referenced
this issue
May 25, 2021
Apollo Server has graphql-playground built in, to the degree that the playground-html renderPlaygroundPage options are a top-level key in Apollo Server config. This has been very useful, but the theme of Apollo Server 3 is to keep its API lean and disentangled from other packages. Every single Apollo Server integration package has the same copy-and-paste code that threads playground options directly into the playground package. Additionally, graphql-playground has is retiring (see graphql/graphql-playground#1143) and merging back into GraphiQL. So it especially doesn't make sense for Apollo Server's API to continue to be defined by Playground. We could just switch back to GraphiQL like in Apollo Server 1, but instead, let's move UI configuration out of the top-level ApolloServer API and move it into our plugin system. And let's make sure that the per-web-framework integration packages don't need to care what UI system you're using. This PR adds a very very very simple static HTML serving API to our plugin system. The point of this system is to support plugins that serve a bit of HTML to load a full UI from CDN, like for Playground, GraphiQL, Explorer, etc, or to serve a splash page linking to other UIs. The point of this system is not to be a convenient way to add app-specific HTML to your app. If you want to do that, just use middleware in your web framework! The point is to make UI plugins that work out of the box with every Apollo Server integration. Because of that, the plugins can do very little: they can serve a single static HTML page. That's it! And you can only install one in your app. We add ApolloServerPluginUIGraphQLPlayground in core, as well as ApolloServerPluginUIDisabled. Like other plugins, if you don't set some UI plugin of your own and don't set the disabled plugin, Apollo Server will auto-install a plugin. In this case it installs the playground plugin though we may change that before 3.0.0. (The mechanism for implicitly installing ApolloServerPluginUIGraphQLPlayground is a bit more complex than for our other built-in plugins because we want user plugins to be able to override the UI, not just other built-in plugins. So ApolloServerPluginUIDisabled prevents ApolloServerPluginUIGraphQLPlayground from being installed at all, but other plugins defining renderUIPage get installed alongside ApolloServerPluginUIGraphQLPlayground and there's logic to make sure they take precedence.) We remove the `playground` constructor option (you can pass configuration options to ApolloServerPluginUIGraphQLPlayground instead), as well as three playground-related symbols exported from all the main packages. While we're at it, we simplify how we set up the Playground HTML: - There was some confusing logic in playground.ts where `defaultPlaygroundOptions.settings` listed some setting overrides... which were not actually used by default... only if you specified something like `playground: {settings: {}}`! We remove these and let the default settings in `@apollographql/graphql-playground-react` be the defaults *always* instead of *most of the time*. - Instead of trying to figure out the path to the GraphQL endpoint via a variety of different mechanisms (including "in the docs, tell you to edit the source to specify `endpoint` yourself), just leave `endpoint` empty by default. This makes the React app choose `location.href` for the endpoint, which should be fine! (Upgrade `@apollographql/graphql-playground-html` to not log a warning when `endpoint` isn't provided, and upgrade `@apollographql/graphql-playground-react` to preserve `code` query parameters on the endpoint so that the Azure Functions docs work automatically.) Also: - Tests that set environment variables (as some of the playground ones do) make me uncomfortable. Added `__testing__nodeEnv` to the ApolloServer and GraphQLOptions interfaces that can be used to test how `process.env.NODE_ENV` affects AS without actually changing the environment. - Inline fastifyApollo into fastify's ApolloServer. - I ended up rewriting a bunch of tests that used `request` to use `supertest` instead (though for some reason we access it via the symbol `request`). Many of these tests had been copied and pasted between packages but I did not consolidate them. Fixes #5159.
glasser
added a commit
to apollographql/apollo-server
that referenced
this issue
May 25, 2021
…5206) Apollo Server has graphql-playground built in, to the degree that the playground-html renderPlaygroundPage options are a top-level key in Apollo Server config. This has been very useful, but the theme of Apollo Server 3 is to keep its API lean and disentangled from other packages. Every single Apollo Server integration package has the same copy-and-paste code that threads playground options directly into the playground package. Additionally, graphql-playground has is retiring (see graphql/graphql-playground#1143) and merging back into GraphiQL. So it especially doesn't make sense for Apollo Server's API to continue to be defined by Playground. We could just switch back to GraphiQL like in Apollo Server 1, but instead, let's move frontend configuration out of the top-level ApolloServer API and move it into our plugin system. And let's make sure that the per-web-framework integration packages don't need to care what frontend you're using. This PR adds a very very very simple static HTML serving API to our plugin system. The point of this system is to support plugins that serve a bit of HTML to load a full frontend from CDN, like for Playground, GraphiQL, Explorer, etc, or to serve a splash page linking to other UIs. The point of this system is not to be a convenient way to add app-specific HTML to your app. If you want to do that, just use middleware in your web framework! The point is to make frontend plugins that work out of the box with every Apollo Server integration. Because of that, the plugins can do very little: they can serve a single static HTML page. That's it! And you can only install one in your app. We add ApolloServerPluginFrontendGraphQLPlayground in core, as well as ApolloServerPluginFrontendDisabled. Like other plugins, if you don't set some frontend plugin of your own and don't set the disabled plugin, Apollo Server will auto-install a plugin. In this case it installs the playground plugin though we may change that before 3.0.0. (The mechanism for implicitly installing ApolloServerPluginFrontendGraphQLPlayground is a bit more complex than for our other built-in plugins because we want user plugins to be able to override the UI, not just other built-in plugins. So ApolloServerPluginFrontendDisabled prevents ApolloServerPluginFrontendGraphQLPlayground from being installed at all, but other plugins defining renderFrontend get installed alongside ApolloServerPluginFrontendGraphQLPlayground and there's logic to make sure they take precedence.) We remove the `playground` constructor option (you can pass configuration options to ApolloServerPluginUIGraphQLPlayground instead), as well as three playground-related symbols exported from all the main packages. While we're at it, we simplify how we set up the Playground HTML: - There was some confusing logic in playground.ts where `defaultPlaygroundOptions.settings` listed some setting overrides... which were not actually used by default... only if you specified something like `playground: {settings: {}}`! We remove these and let the default settings in `@apollographql/graphql-playground-react` be the defaults *always* instead of *most of the time*. - Instead of trying to figure out the path to the GraphQL endpoint via a variety of different mechanisms (including "in the docs, tell you to edit the source to specify `endpoint` yourself), just leave `endpoint` empty by default. This makes the React app choose `location.href` for the endpoint, which should be fine! (Upgrade `@apollographql/graphql-playground-html` to not log a warning when `endpoint` isn't provided, and upgrade `@apollographql/graphql-playground-react` to preserve `code` query parameters on the endpoint so that the Azure Functions docs work automatically.) Also: - Tests that set environment variables (as some of the playground ones do) make me uncomfortable. Added `__testing__nodeEnv` to the ApolloServer and GraphQLOptions interfaces that can be used to test how `process.env.NODE_ENV` affects AS without actually changing the environment. - Inline fastifyApollo into fastify's ApolloServer. - I ended up rewriting a bunch of tests that used `request` to use `supertest` instead (though for some reason we access it via the symbol `request`). Many of these tests had been copied and pasted between packages but I did not consolidate them. Fixes #5159.
Merged
3 tasks
|
This is a horrendous idea and I am struggling to understand why GraphQL makers would want to create such a dependency to where users have to always be online in order to develop. In what world does that make sense? |
|
Why would they have to be online? GraphiQL works offline? Please explain? |
|
Their is a plug in to use the local development environment search for it
and you can test locally and you can also share it via their playground for
some one if you want.
…On Fri, 15 Oct 2021, 01:33 coolcomfort, ***@***.***> wrote:
This is a horrendous idea and I am struggling to understand why GraphQL
makers would want to create such a dependency to where users have to always
be online in order to develop. In what world does that make sense?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1143 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AK3MBK3AEWKE4BFJDFTMXP3UG5LBZANCNFSM4LZK4XYQ>
.
|
I believe it's is because I had to add new playground address if (!__prod__) corsOriginList.push("https://studio.apollographql.com"); |
|
We've decided it no longer makes sense to merge the projects, though they will continue to use tons of shared logic in the form of the editor mode. It made sense at the time that Prisma offered playground to us, but it's clear the community wants to move this project forward. I made a proposal to this effect a year ago, where we were imagining a re-built playground called "graphql-ide" using The playground community is free to choose whether they would like to:
other choices
We are seeking maintainers to review PRs and help steer the direction of the project here: |
|
@schickling are you still interested in coming back to the project? |
|
Thanks for pinging me about this @acao. Unfortunately I don't really have the time right now to contribute to the project in any meaningful way but I'm very happy to see that the project is still being pushed forward as I really enjoyed working on the early versions of GraphQL Playground. I think there's still a lot of untapped potential which we explored in the designs for V2 back a few years ago. Thanks for your work on this! ❤️ |
|
For reference: #1366 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://foundation.graphql.org/news/2020/04/03/web-based-graphql-ides-for-the-win-how-why-playground-graphiql-are-joining-forces/
We are happy to announce that GraphQL Playground and GraphiQL are joining forces.
In the next few days a formal blog post will be going out that talks about some of the changes taking place, new features you can expect, and existing ones you can count on staying.
TLDR; you will be able to do everything you were able to do in the latest graphql playground, and hopefully much more
Archiving this Repository
After a few minor bugfixes and a final release, we will archive this repository under the official GraphQL github organization. We will at least try to upgrade codemirror-graphql and the LSP to eliminate a few bugs we've addressed in those underlying packages. You will still be able to fork it and create other projects with it if you like.
Any further issues about the future GraphiQL preset for GraphQL Playground should be created in the graphiql repository for now, and will be fielded by the Playground Preset team. Eventually the playground preset may or may not have it's own repository, or it may join the monorepo. We may also migrate relevant old issues (feature requests especially) from this repo to a new repo for playground
Archiving the Slack Channel
The Prisma Slack channel for Playground will be going away. In its place is a channel on the GraphiQL Discord Group. Check it out here.
Migrating to the Forthcoming Playground GraphiQL Preset
A migration guide will be provided, as some settings will change, but expect a fairly straighforward transition from the previous settings to the new settings format. We will be using graphql-config 3.0, so be sure to pay mind to the new and improved configuration format!
Many of the same settings that the Prisma GraphQL VSCode Extension (which also uses the Official LSP) currently supports will also be supported, such as custom directives, custom scalars, custom types, "hidden" fragments, custom parsing rules and more (further documentation forthcoming).
Call for a Playground Preset Team
The playground preset will need a team of contributors to help develop and maintain the playground specific preset and plugins - the doc explorer, headers tab, tracing, etc.
They will be in charge of managing the entire playground in a product sense as well, and should consult with playground users here to ensure that the product continues to improve at the direction of the graphql playground user community.
Initially, they can help advance the core GraphiQL Plugin API (graphql/graphiql#983) for these purposes, and should be able to begin developing the custom preset as soon as the first
graphiql@1.0.0-betalands.Get Updates
If you want to be part of the Playground Preset team, subscribe to graphql/graphiql#1443 and the plugin API meta-issue referenced above
The text was updated successfully, but these errors were encountered: