Custom GraphiQL middleware

[eugenehp]

Hi Lee,

I just finished draft version of GraphiQL that supports HTTP headers.
I know there are multiple discussions about keeping the original GraphiQL version lean and protocol independent, which makes sense to me.

So the question is what's the best way to structure the middle ware here, so we can specify our own custom versions.

At the moment I'm using non flexible solution:
graphQLServer.use('/graphiql', express.static('graphiql'));

But I would want to see something like this possible:

import graphiql from 'graphiql-headers';
app.use('/graphql', graphqlHTTP(request => ({
  schema: MySessionAwareGraphQLSchema,
  context: request.session,
  graphiql: graphiql
})));

What would be accepted as PR?

Thanks for your time on this.

[lacker]

What's wrong with just mounting it on a different URL like your example of graphQLServer.use('/graphiql', express.static('graphiql'));?

Although graphiql itself is generic, I don't think that the version of graphiql that is exposed by express-graphql when you pass graphql: true has to be generic. I think it would make sense for that to include express-specific features, including some knowledge of the transport layer. And in particular doing something sane in conjunction with middleware like express-jwt or express-session.

[eugenehp]

@lacker thanks for the heads up, the idea was to be able to incorporate custom versions of the GraphiQL interface in the same place like https://github.com/eugenehp/graphiql

So changes are required for both express-graphql and graphiql

As we discussed it last time on reactiflux QA channel, this is something that we can do over a PR.

Let me know what's your vision of making this happen?

[lacker]

If we used this API, and then we wanted to support e.g. headers that express-jwt or express-session use, would there have to be forks of graphiql for graphiql-jwt and graphiql-session and so on, one for each express middleware? It seems tricky to maintain a fork of graphiql, because it'll be hard to keep it up to date, so it seems like we should avoid an API that can only be used by forks of graphiql.

How exactly does your fork support HTTP headers? Is there like some UI to add them, in the client? It is not clear to me from looking at the code. Maybe there is some way to get this behavior without modifying graphiql too much - currently express-graphql is already doing a lot of hacky stuff to get graphiql running, but graphiql isn't doing much hacky stuff, so we are more justified hacking around in express-graphql to get this working.

It would be so nice if an app using e.g. express-jwt had a way with a couple of lines of code to get graphiql to sanely handle the auth data... I do really want this feature to get in in some way ;-)

[stubailo]

Note - Apollo Server has graphiql split out from the actual GraphQL endpoint already: http://docs.apollostack.com/apollo-server/graphiql.html

I think part of the issue is that it's not easy to configure GraphiQL other than creating a totally new app using the NPM React component version, which is quite a bit of work.

[j0k3r]

@lacker the diff is pretty much what you are looking for about the UI graphql/graphiql@master...eugenehp:headers#diff-42bf41376a5f07ac441dbb48ade3a958

[lacker]

Ah, interesting! Hmm......

OK so that UI is allowing you to do what you need to do develop, but it still seems like a frustrating developer experience. It means you have to know precisely how your client library constructs a header and then do it manually. IMO it would be nicer to explicitly support some number of common auth strategies, like setting a JWT token, or using http basic auth, and so on. Also the UI would probably be better if it was hidden a bit - like if there was a drop-down to select authentication, and the default might be "none" but you could select some other things like jwt, etc. Thoughts?

[eugenehp]

@lacker that was just a draft to test out the idea. The design of GraphQL aims to keep it lean, and headers or authorisation strategies will make it even more complicated.

As some other developers suggested, it would be great to have that as a middleware on top of GraphQL.

IMO it would be nicer to explicitly support some number of common auth strategies, like setting a JWT token, or using http basic auth, and so on

What would be your ideal list of auth strategies here?

[lacker]

Keeping GraphQL and GraphiQL lean is great. I'm just talking about express-graphql. IMO it makes sense to support express-isms in express-graphql. So when you run express-graphql, it makes sense for its embedded graphiql to support the typical authentication strategies you are likely to use with an express-graphql app. For an ideal list of auth strategies, I'd look for the most popular express authentication libraries. I think those are express-jwt, express-session, and passport. I could be missing some though.

BTW I am working on adding an example with auth to the docs or this repo and after poking around with some auth strategies I agree that adding a separate middleware is too much of a pain. It would be much nicer if something usable was built into the graphiql: true behavior.

[stubailo]

Here's what we came up with as an interim solution for apollo-server: apollographql/apollo-server#133

It's clearly not optimal, but it works for now until we come up with a better idea.

[wincent]

Going to close this one in favor of continuing any further discussion about middleware in #113. We have a few scattered issues which are all talking about the same thing (making express-graphql more extensible and reusable), and there are a number of possible ways forward; I think the discussion will be more effective if it takes place all in one spot. Thanks for the input so far!