Use server's own graphiql package instead of from CDN

[ephemer]

graphql-server currently manages its own version of GraphiQL in package-internal code. Maybe I'm missing something but this seems unnecessary given we have npm/yarn.

Is there anything stopping us from serving the version of graphiql installed on the server, instead of doing this? That way we wouldn't need to manage the version separately to what is available on npm.

I realise this would involve serving files from the node server in some way, which is an anti-pattern in production, but I wouldn't expect the proposed (or present) method to be used in production as is anyway.

I'm interested in others' thoughts about this. It seems a shame to always be at least a little bit behind the cutting edge in terms of Developer Experience just because we're using graphql-server.

[stubailo]

Ironically, we're actually ahead of express-graphql: https://github.com/graphql/express-graphql/blob/87fc6d527d0d8fe128130a26bef39e5be2b26da5/src/renderGraphiQL.js#L19

Anyway, I agree it would be a good idea to see if we can get it from npm, but that is a bit more complex because you need a build system, etc. Perhaps we can start by making a list of what we need to do to make this happen?

[stubailo]

Oh lol I just realized you sent that PR. But yeah, we essentially copied that logic from express-graphql.

[DxCx]

hi @ephemer,
i don't see why this is better then just serve from CDN..?
the thing is that to make it work from a package there is much work to be done,
and i can't the find the reason to invest time into that.. can you explain us please? :D

[stubailo]

I think the main reason is to stay up to date with the newest version of GraphiQL, and not have to wait for the CDN url to be updated. Perhaps we can have an option in renderGraphiQL for the version number so that it can be increased manually when necessary?

[DxCx]

yes @stubailo i agree with you, we can set default in const and pass another option.
great idea! :)
@ephemer what do you think of the solution?

[ephemer]

Oh yeah! That's easy and solves the problem, nice @stubailo

[DxCx]

cool @ephemer can you please open another issue for implementing this and close this instead.
also if you want to submit the PR for the actual change, you are welcome =)

[helfer]

This would be a great project for contributor week btw 😉

[ephemer]

@helfer sure, we have a deadline this week so I don't think I'll get to it but I'd be happy to give it a shot when I have a bit more time on my hands

[helfer]

I still think this would be neat to implement.

[jacobbogers]

Hi, anyone working on this already, can I help out or I will start myself

[luchillo17]

I have an issue with the CDN for react.min.js, however if i change the js string to react.js it works ok:

[stubailo]

@jacobbogers or @luchillo17 please feel free to get started! I think this would be a great improvement.

[gilesbradshaw]

Definitely a good idea not only for when the cdn goes down but also for when working in remote locations without internet.

[gilesbradshaw]

this is related to #506

[stubailo]

Does anyone want to sign up to get started on this? Shouldn't take more than a few hours to set up the build and make it run from a local setup.

I'd say a script that just downloads the CDN version and inlines it into the package, or builds with Webpack, would be perfect.

[nadavten]

any news ? common

[rbureau85]

is this a thing yet?

[stubailo]

There's a work in progress PR here: #673 please help!

[abernix]

Apollo Server 2.0 ships with graphql-playground as a direct dependenct, rather than a CDN-hosted version, so I believe this issue can be closed. Happy to reopen if anyone feels different. Thanks for reporting this originally!

#1421

[penx]

Apollo Server 2.0 ships with graphql-playground as a direct dependenct, rather than a CDN-hosted version

Using apollo-server@2.1.0 and following the getting started guide I get a graphql-playground instance using assets from an external CDN, so I am pretty sure this issue is still open.

As above, there are more details in #1421 and I am working on a fix in #1734

[abernix]

I was incorrect above, this is indeed still an issue, but let's track it in #1421.. Thanks for your work in #1734 — we'll consider how to make that more permanent in Apollo Server, though I think your demonstration in #1734 (comment) is pretty close to what that will end up being (but less explicitly).