Graphql-WS support - provide graphiql playground plugin support

[sgentile]

I have seen the note around using graphql-ws, that note has been around for quite some time. And now apollo even has another playground that doesn't support graphql-ws.

Please create a plugin option for graphiql so it can be used for graphql-ws.

I can understand not wanting to rewrite your playground, but how about at least creating a plugin for something that supports graphql-ws

Thanks

[glasser]

The lesson we've learned is that it's better to provide stable interfaces that the community can use to interface third-party packages with the project instead of providing a limited set of hard-coded integrations with third-party packages. Integrations with software are best maintained by folks who actually use that software, not by a core team. (For example, we are hoping to finally get started on #3184, which will make it easier to build integrations between Apollo Server and arbitrary HTTP server frameworks while removing the need to for the core team to be experts on 9 different web frameworks.)

That's why we replaced the hardcoded integration with a single unmaintained web UI with a plugin system that lets you install any web UI within your server.

I think it would be great if you could easily use GraphiQL in your Apollo Server server via a landing page plugin. But we're going to allow the GraphiQL project or somebody else who uses GraphiQL to write and maintain the plugin instead of maintaining a link to code that nobody at Apollo deploys and operates. I'd be very happy to add a link to such a plugin to the Apollo Server docs!

(We really do hope to bring full subscription support to the Apollo platform soon, and at least my personal opinion would be that it should probably be based on graphql-ws, but that's not particularly helpful to you right now.)

[sgentile]

What I find interesting then is how https://www.apollographql.com/docs/apollo-server/data/subscriptions/#the-graphql-ws-transport-library

"This page explains how to connect the subscriptions-transport-ws library to your Apollo Server. However, as of 2021, this library is not actively maintained. A newer alternative to subscriptions-transport-ws called graphql-ws is currently more actively maintained, and its README explains how to use it with Apollo Server."

There is no example on how to use although your own documentation. It says 'explains how to use with Apollo server' - and yet it does not (no links in their readme actually show using with Apollo Server.

Apollo Server is your project, the playground is your project, your using an older library that isn't maintained, and yet the response and documentation for Apollo server provides no examples how to use it and it has a broken playground.

[glasser]

Playground is not our project; it’s a third-party project that we shipped with Apollo Server 2 as the only option and with Apollo Server 3 for backwards compatibility.

I totally agree that we should be teaching our users how to use a maintained subscriptions library (graphql-ws) rather than an unmaintained one (and eventually that subscriptions should be built in and fully supported). Our path to this is going to be supporting graphql-ws in our first-party UI (Explorer), which is being actively developed as we speak
and should be shipped Q1 at the latest. Then we’ll feel comfortable swapping out the examples in the Apollo Server docs to recommend graphql-ws instead of subscriptions-transport-ws.

And again, I’m more than happy to recommend a GraphiQL landing page plugin in our docs; we worked closely with the GraphiQL team to fix a recent security issue in GraphiQL and GraphQL Playground and they (or other community members) are absolutely capable of writing the small amount of glue code required to serve GraphiQL’s HTML with appropriate configuration options in the form of a plugin. What we don’t want is for our team (who doesn’t even use GraphiQL ourselves) to be responsible for the release cycle of a plugin whose releases will mostly be tied to new GraphiQL constructor options and the like.