Postgraphile: Feature Request: PostGraphiQL "Analyze"

Created on 21 Mar 2019  ·  6Comments  ·  Source: graphile/postgraphile

I'm submitting a ...

  • [ ] bug report
  • [x] feature request
  • [ ] question

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):

hasura-graphiql
hasura-analyze

Their GraphiQL implementation can be found here.

✨ feature 🔍 GraphiQL

Most helpful comment

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).

All 6 comments

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:

  1. baseline -- Query editor with autocomplete, Explorer, and Docs
  2. power_user -- Advanced features of the graphiql interface including using subscriptions and setting headers
  3. api_developer -- Features such as Analyze that help the developers building the API
  4. postgraphile_developer -- Features that might help developers of postgraphile itself

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).

Was this page helpful?
0 / 5 - 0 ratings