Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading GraphiQL #98

Closed
swarthout opened this issue Aug 17, 2016 · 7 comments
Closed

Upgrading GraphiQL #98

swarthout opened this issue Aug 17, 2016 · 7 comments

Comments

@swarthout
Copy link

Now that graphiql is decoupled from the rest of apollo server, we have the opportunity to provide an upgraded version of graphiql. The website http://toolbox.sangria-graphql.org/graphiql has a really nice one with support for multiple queries, multiple endpoint urls, and headers. The repo for the above website is here: https://github.com/OlegIlyenko/graphql-toolbox. I was wondering if you would accept a pull request to implement this new graphiql in apollo server?

@helfer
Copy link
Contributor

helfer commented Aug 17, 2016

Yeah, I think that's a great idea! My preferred way would be that you make a PR which adds an optional argument to the GraphiQL middleware that lets users provide a custom renderGraphiQL function, and then wrap the one from graphql-toolbox in such a function either in their package or in a separate package that you create just for that. Does that make sense?

@swarthout
Copy link
Author

I understand what you want for the graphiql middleware, but I have a few questions about the implementation. Right now the current graphiql middleware returns the html page as a string, so would my package simply expose a function that returns a different stringified html page with the modified graphiql? I understand you don't want to add the overhead of using a module bundler like webpack, but returning strings doesn't seem very sustainable.

@helfer
Copy link
Contributor

helfer commented Aug 18, 2016

Personally I think it would make more sense to use a bundler like webpack to build it, because that would also let you use it offline (right now it uses some CDNs). If you put it in a separate package, then you can build the bundle in whichever way you want. The only requirement is that it exports a function with the same signature as renderGraphiQL. Once you have that, I think the modifications to apollo-server required to make it work with express, hapi and Koa will be minimal.

@helfer
Copy link
Contributor

helfer commented Aug 19, 2016

@swarthout let me know if something I said doesn't make sense. I think it would be really cool if you could do this, and I'd be more than happy to make the necessary API changes to support any GraphiQL clients that people want to use.

@swarthout
Copy link
Author

What you said makes sense, I'll see what I can do. I am moving next week so I'm going to be super busy for a little while, but I'll check in with progress and questions.

@eugene1g
Copy link

I wanted to use the latest GraphiQL, but did not want to bother with webpack etc. Instead I created a custom route with a static HTML file to serve the always-current version from CDN. Maybe someone else will find it useful - https://gist.github.com/eugene1g/d062c26603845ba839e049fc4be578c7

@helfer
Copy link
Contributor

helfer commented Oct 31, 2016

see #192

@helfer helfer closed this as completed Nov 29, 2016
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants