Apollo-server: Bring back GraphiQL

Created on 23 Oct 2020  路  6Comments  路  Source: apollographql/apollo-server

Hi. This is in context with this announcement: https://foundation.graphql.org/news/2020/04/03/web-based-graphql-ides-for-the-win-how-why-playground-graphiql-are-joining-forces/

Now that Playground will have no more enhancements, it makes sense to replace Playground in apollo with GraphiQL instead.

Most helpful comment

Part of the theory for Apollo Server 3 is that we are trying to reduce the number of dependencies on third-party software out of the box, which have led to a lot of busywork in AS2 keeping dependencies up to date (and lots of times where we can't upgrade a dependency without it counting as a major version change for AS itself). So we are more likely to work towards a world where neither graphql-playground nor graphiql ship directly with AS but there are very easy patterns to install one or both yourself (as well as making it easy to use Explorer if you'd like, which will have fewer dependencies).

All 6 comments

Given this comment https://github.com/graphql/graphiql/issues/983#issuecomment-751279365 and the message at the top of graphiql's github repo that says Note: The primary maintainer @acao is on hiatus until December 2020 Looking for the GraphiQL Docs?: This is the root of the monorepo! The full GraphiQL docs are located at packages/graphiql.

What is the future of this? We're facing some bugs with the playground that ships with apollo and trying to figure out how to navigate it. Is the 2.0 project in graphiql still even a thing?

Part of the theory for Apollo Server 3 is that we are trying to reduce the number of dependencies on third-party software out of the box, which have led to a lot of busywork in AS2 keeping dependencies up to date (and lots of times where we can't upgrade a dependency without it counting as a major version change for AS itself). So we are more likely to work towards a world where neither graphql-playground nor graphiql ship directly with AS but there are very easy patterns to install one or both yourself (as well as making it easy to use Explorer if you'd like, which will have fewer dependencies).

I understand that initiative. My concern is that if you guys aren't working on your fork anymore, and graphql-playground isn't working on theirs anymore, that leaves one playground in the ecosystem and it looks mired in an over-complicated re-write that is far, far, far beyond just a simple playground and I'm a bit skeptical if it will ever be built.

Here's the proposed ecosystem from the repo https://raw.githubusercontent.com/graphql/graphiql/main/resources/images/proposed-ecosystem.jpg . That's so, so, so, so much more than a playground, and I'm struggling to wrap my mind around why. But maybe it's because I'm not fully looped into that project.

Are we going to be left with no playground? That seems like a pretty fundamental problem for AS.

I mean, at the very least, the existing playground code does work even if it may be not super actively maintained.

And while using Studio may not be the choice that all users of Apollo Server are making, we did build Explorer (and Studio Dev Graphs) because we think it's a tool people will enjoy using for their development.

The bummer of that answer is that Explorer only works if you connect the graph to Apollo's enterprise tools. It's unfortunate, because that means that the reason there is no movement to update the playground is because it's being leveraged as an incentive to use the paid tooling provided by Apollo. For now, it appears free accounts have access to Explorer at no cost, but is it unreasonable infer where this is going?

We don't have any plans to require a paid plan to use dev graphs with Explorer, and I personally think it would be a shame to change that in a world where there's no actively maintained open source GraphQL UI (neither GraphiQL nor graphql-playground are maintained). It is certainly understandable if you don't find that convincing.

Was this page helpful?
0 / 5 - 0 ratings