GraphiQL question/feature request: show graphql endpoint being queried

[joshft91]

My team is currently using GraphQL Playground that's shipped with Apollo Server, but due to the fact that Playground is no longer maintained and GraphiQL is now preferred, we are looking to switch. I'm currently running GraphiQL locally as outlined here.

One thing I appreciated about the GraphQL Playground is the ability to see which GraphQL endpoint was being hit/queried as seen in the screenshot below. Is this possible in GraphiQL or GraphiQL v2 that is being worked on?

If this wasn't the appropriate place to ask let me know and I can direct my question appropriately. Thank you!

[acao]

This might be good to consider as a 3.0.0 feature. The current API doesn't allow users to specify a UI directly, instead the fetcher takes this in as an internal detail, however the idea of making (multiple) URI endpoints a configuration feature in 3.0.0 is something that could make sense!

This would work if, for example a simple uri prop or a graphql-config like config object could conditionally be provided instead of the required fetcher. This would require props overloads but it would enable us to have per-endpoint headers, fetcher configuration, etc manageable in the UI

[thomasheyenbrock]

Hey @joshft91 👋 just wanna ask a clarifying question: Is your feature request just about showing the one URL that's used to send queries to? Or is it about adding support for querying multiple endpoints in a single instance of GraphiQL?

[joshft91]

Hey @acao and @thomasheyenbrock 👋 - thanks for the responses!

Good clarifying question - I was in the middle of a response to do just that. While I like the idea of querying multiple endpoints, my request/question was simpler (famous last words): display/show (read only) the URL that's configured in the fetcher essentially. It seems that this could be useful to me as a UI user of GraphiQL to know where my queries are being sent.

I believe this could even tie in with #2485 which seems like it's basically asking for a refresh button to trigger the introspection query. Something like what GraphQL Playground does now, just without the ability to specify a different endpoint.

Hope that makes sense!

[thomasheyenbrock]

Thanks for clarifying 🙌 We'll implement schema reloading with the new design that will ship with v2. The button for that will likely be placed in a menu or dialog. There will also be a keyboard shortcut for that (probably Cmd/Ctrl + R). I don't see an obvious spot where we could show the endpoint in the new design, but this should be solvable in future iterations.

@acao Sounds like we won't need a new major for that, so labeling this just as "enhancement".

[acao]

@thomasheyenbrock another pattern we can borrow from GraphQLPlayground is multiple service-layer components, which it seems you're already moving to to some degree.

GraphiQL could remain the component you use when you want to provide fetcher directly, and then GraphiQLEditor or some such could be more heavy-weight and act as an abstraction around GraphiQL and createFetcher() and eventually createRouter() (simple query params parser, maybe more some day?) and other details i imagined might be useful at this level.

For later major versions, 4 or 5 even at this point, it could eventually be something like this, like playground but with plugins. Perhaps the projects idea still makes sense though

const token = import.meta.env.TOKEN

// we could even adhere to `graphql-config` format, which this is an adaptation of
const projects = [
  { 
    name: "local",  schema: "localhost:3000/graphql"
  }, 
  { 
    name: "stage", 
    schema: "https://myschema.com/graphql", 
    headers: { Authorization: `bearer ${token}` } 
  }
]
<GraphiQLEditor
   projects={projects} 
   settings={/* JSON string like playground or perhaps object */} 
   plugins={/*array of components and/or modules definitions or objects*/} 
/>

which opens us to other playground-esque service layers for server middlewares and beyond! there may be other issues with this approach though, I would be happy to hear other suggestions!

Then you open up so many options if we have some degree of graphql-config compatibility. For example, vite & webpack plugins to automatically build a graphiql instance from your graphql-config, and perhaps even pre-load query collections from your codebase when we support that in later versions

[acao]

playground has so many great service layer design patterns that I want to clone for the more modern era haha! but one at a time, one at a time

[thomasheyenbrock]

@acao great ideas! But should we keep this issue scoped for now on showing the endpoint somewhere in the design and open up another one that focusses on multi-project support? (Maybe there already is one?)

[SachaG]

Is your feature request just about showing the one URL that's used to send queries to? Or is it about adding support for querying multiple endpoints in a single instance of GraphiQL?

Actually if I may I'd like to put in a vote for supporting querying multiple endpoints in a single GraphiQL instance. That would be super useful!

[acao]

That is part of this feature request!

Lets track it here, since it documents the architectural changes needed to achieve this

@thomasheyenbrock in order to even show the url, we will need to make fetcherOpts required over fetcher prop. If fetcher prop is passed, then we cannot track the url in state, thus the proposal