Comments (10)
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
.
from express-graphql.
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.
from express-graphql.
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?
from express-graphql.
@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?
from express-graphql.
@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?
from express-graphql.
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 ;-)
from express-graphql.
@lacker the diff is pretty much what you are looking for about the UI graphql/graphiql@master...eugenehp:headers#diff-42bf41376a5f07ac441dbb48ade3a958
from express-graphql.
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.
from express-graphql.
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.
from express-graphql.
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!
from express-graphql.
Related Issues (20)
- depth-limit HOT 1
- Is there a way to customize a logger HOT 1
- Unhandled errors does not provide mutation or query name HOT 1
- Graphiql playground not displayed in the browser HOT 1
- UnhandledPromiseRejectionWarning: Unhandled promise rejection HOT 1
- Why isn't the callback of app.listen() called when using express-graphql middleware? HOT 4
- Build when installed from GitHub HOT 1
- throw new MiddlewareError(`Type ${type} exists in middleware but is missing in Schema.`);
- TypeScript - merge declarations for request and response types
- Cannot install with graphql 16.0.1 HOT 10
- Update GraphQL Schema at runtime HOT 4
- Graphql 16.2.0 support HOT 9
- Processing timeout HOT 1
- About compatible version for an old graphql and node
- Swallow GraphQL errors by Express HOT 6
- Peer dependency error on new installation of graphql HOT 8
- Unmet Peer version, need to update supported dependencies HOT 9
- revert revert "Allow custom handling of runtime query errors" HOT 1
- Unable to find Prisma Client in GraphQL context. Please provide it under the `context[\"prisma\"]` key. HOT 1
- Support for running method on every call
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from express-graphql.