Add "headers" pane, similar to the graphql variables pane

[ryancole]

I see several past issues asking for some way to modify headers, via graphiql. I really think it'd be great if you could add some custom headers. It's kind of a speed bump when using express-graphql, with graphiql, and you need to add a custom header to proceed testing / writing your graphql schema.

Would it be acceptable to add a pane, similar to the graphql variables pane, that just lets you provide some custom headers, in JSON-esque format? No auto complete needed. Just an expandable pane that takes in a JSON payload and interpolates the values into the headers being sent along with the request.

Would this be a pretty minimal addition?

I see in past issues, most responses are to use additional third party tools, or write your own graphiql plugins, etc. This is an issue that comes up, for me, every time I use graphiql in a new project. Wouldn't this just make sense as a pane at the bottom, below the variables pane?

[asiandrummer]

@ryancole first of all thanks for the suggestion. I'll try to elaborate why I still think GraphiQL shouldn't be associated with concepts other than what it is now.

Just an expandable pane that takes in a JSON payload and interpolates the values into the headers being sent along with the request.

How I'd like to think of what GraphiQL is in a minimal sense is that it's just a React component that needs to be rendered in some other DOM to render a web IDE for query/variables. In my opinion GraphiQL should not deal with any other things than rendering itself - it's intentionally meant to be lean and simple for the purpose of easy extensibility/usability.

One of the features of this IDE is an ability to execute a query and gets back the result, and although this may suggest that GraphiQL does operations over the wire, it actually doesn't know/care about the network at all. All GraphiQL requires is a fetcher function to be passed in at the time of the component mount, and this fetcher function could work completely local if users want it to be. For this reason, a "custom headers" pane does not constitute as an absolutely necessary component to render/use GraphiQL in my honest opinion, hence we decided not to include it. We think any network-related configuration/operation should be dealt with before/in the fetcher level.

Having said all this, I do see how including the ability to add custom headers in express-graphql would be useful, and believe that express-graphql is the correct place to add such a behavior as a sort of an "add-on". Would that help you to simplify your workflow?

[ryancole]

@asiandrummer Sounds reasonable to me. Thanks for the explanation.

[Durisvk]

@asiandrummer No that's absolutely not reasonabe... You've made me angry right now. I need that feature for my work. I am going to publish my own version of graphiql with that feature and I don't care about license or some law fucking issues. I will let you know about my progress in this thread.

[asiandrummer]

@Durisvk as I inferred from my latest comment in this issue, building out another application that embeds this GraphiQL component with custom headers support sounds good to me - in fact and in addition to your recent PR, there are some more examples you can take a look to achieve that goal.

• Examples from individual contributors in this issue
• http://toolbox.sangria-graphql.org/ (powered by Sangria)

[Durisvk]

Ok so I've finished it...
Here are the links to the library files:
https://cdn.jsdelivr.net/npm/graphiql-custom-headers@1.0.0/graphiql-custom-headers.css
https://cdn.jsdelivr.net/npm/graphiql-custom-headers@1.0.0/graphiql-custom-headers.js
https://cdn.jsdelivr.net/npm/graphiql-custom-headers@1.0.0/graphiql-custom-headers.min.js

Here is a simple example of how to use it:
https://github.com/Durisvk/graphiql

It's really simple, you don't have to do almost any changes to your current running app.

And it's also available on NPM: https://www.npmjs.com/package/graphiql-custom-headers

This is how it looks like: http://imgur.com/a/3VQDT

I've also implemented it already to my project: https://github.com/Durisvk/senegraph
so it's already available on HapiJS servers. Somewhere in the future I would like to implement it also on express.

Hopefully you'll like my solution @ryancole ...

[PetrSnobelt]

It looks like it doesn't work for WebSockets...

[Siyfion]

Whoa, I think this topic may have got a little out of hand?! But, in principle I too agree that adding a small amount of functionality to allow the user to add a JWT token into the requests would, for a vast amount of users, make GraphiQL infinitely more powerful & useful.

I can see the logic on both sides, but my thoughts are that why not look at a JWT token in the same vein as a variable? It's just the manner in which it's "attached" to the request that differs, but it's no less of an argument to the GraphQL server?

[PetrSnobelt]

Will be great if it is possible to add jwt token to websocket initial request instead of adding it into params, because then connection authorization can be done in verifyClient, but have no luck to do this with graphiql

[asiandrummer]

@Siyfion @PetrSnobelt Hi guys! The issue with adding a functionality for a specific technology/tool (e.g. custom HTTP headers) is that GraphiQL should just be a simple React component that provides the IDE functionalities. Also, GraphiQL should not (and does not) care about how the network is configured to send query and receive responses. All it requires is a fetcher function that sends the query and receives the results after execution.

Toos like this that I referred above is a good example how a customized GraphiQL tool is built to support specific usages. It could be as simple as a React container that wraps GraphiQL, which then does whatever your app needs to do to power GraphiQL for your use case.

[PetrSnobelt]

It looks like adding/modify headers for websocket is not possible/recommended, so I stay with connectionParams.
https://github.com/apollographql/graphql-subscriptions/blob/master/.designs/authorization.md
So for me it is OK

[imolorhe]

You can always use other GraphQL tools that add support for custom headers. GraphiQL was built to be minimal and that's a reasonable decision to make. It's an easily customizable tool and you can always add those extra customizable options yourself.

Having said that, you can checkout https://github.com/imolorhe/altair if it works for you.

[Maxtermax]

By far the best solution for this issue for now is https://github.com/imolorhe/altair

[praveenweb]

If anyone's looking for GraphiQL with Headers pane, check out https://graphiql-online.com.

Its an online version of GraphiQL with configurable endpoint and headers.

[Loschcode]

Honestly, I'm just starting with GraphQL for one of my side-projects and I'm already stuck because there's no way I can transmit tokens via headers. Minimalist ok, but it's not that hard to let users add headers for development purpose knowing JWT and such are literal standards.

@Durisvk was right.

[Betree]

The theory is indeed reasonable but in practice graphiql is embedded in many libraries like https://github.com/graphql/express-graphql or https://github.com/absinthe-graphql/absinthe that expose it as a ready-to-use client for your API (not a react component that you should embed in your app yourself).

The fact that it doesn't support customizing headers makes it not ready-to-use for most businesses. The majority of the GraphQL APIs out there needs to authenticate requests based on a header.

I think this issue is legitimate and should be re-opened.

[Betree]

As a reference this what Absinthe did to add headers:

[scope2229]

Hi just to add my two cents. The main use of graphql with the company i work for is mobile applications. It seems like while yes you want it to be minimal having a panel to add headers is a MUST. Without it graphiql is just useless. If you have authenticated queries or mutations you can not test or run them because no auth token is provided. I see graphiql as a quick and simple tool to check/view/test API's/queries & mutations. To run those queries and mutations to see an example of the output. It really doesnt make sense at all that there is no way to add an auth token to the headers. without it you cant run graphiql anyway.

[acao]

something with even better UX is already in the works, but the plugin system needs to come first! HTTP support for features like these will be via a plugin, as many implementations do not use HTTP/HTTPS at all