I'm submitting a ...
PostGraphile version: v4.4.0-beta-6
Hasura's modified GraphiQL adds an "Analyze" button, which provides the generated SQL and execution plan (presumably output from SQL EXPLAIN). I think that would be really neat to add to PostGraphiQL!
Here are some photos (seems to get no mention on their site or their docs):


Their GraphiQL implementation can be found here.
You can currently get this using the DEBUG variables (see Debugging in the docs) but it’d definitely be nice to add it to GraphiQL
Yeah, one thing that would be nice about it being in GraphiQL is that you get just the query you want. I find in my development flow, I find API issues when working on the frontend, and it can be hard to find the important query in a long stream of console output.
Please keep in mind if graphiql is being used as a friendly tool for users to interact with an API powered by postgraphile, the API provider likely wouldn't want the actual SQL queries to be seen by their end-users, so please make this a configuration option. :)
Good point, @deinspanjer; this will only be added to the enhanced GraphiQL interface which is intended for development 👍
So for the version of graphiql I'm embedding in our site, the explorer will be a fantastic asset to users, especially people who may be working with graphql for the very first time.
Other features that are currently under the enhanced flag such as subscriptions do feel much more advanced, but even there, if the user is a developer working with our graphql API, it seems like making that feature available to them to develop is worthwhile.
Something like Analyze is clearly in a different class though. It is exposing internals that the producer of an API would never want to be seen externally.
It seems to me that these use cases don't really fit together in a single "enhanced" flag. Have you thought about maybe breaking it out into a few different levels? No attachment to these, but just tossing them out there for brainstorming:
This was implemented in #1179 via the --allow-explain flag. I prefer per-feature flags rather than class-of-feature flags (because I may not classify the classes in the same way that users might).
Most helpful comment
This was implemented in #1179 via the
--allow-explainflag. I prefer per-feature flags rather than class-of-feature flags (because I may not classify the classes in the same way that users might).