Graphql-playground: Use Apollo Link

[tlvenn]

It seems like it would be a pretty good idea to leverage Apollo Link to deal with how to interface with the Graphql endpoint, how to deal with subscriptions and more broadly standardize how to execute any Graphql ops in a more transparent / pluggable way.

People would be able to provide any composed link they want to Playground and it would work transparently.

This would simplify the code around subscriptions and make Playground integration a lot more agile.

For example, my use case is around how subscriptions are handled right now which is hardcoded to use subscriptions-transport-ws. In my case, our backend is written in Elixir using Absinthe which leverages Phoenix channels so a special client is needed to send ops over ws.

We have already an Apollo Link for it and should Playground support it, it would be trivial to have Playground works with Absinthe.

@timsuchanek what do you think ?

[kbrandwijk]

Passing in a Apollo Link when integrating the Playground in your own app sounds like a great idea to me!

[schickling]

Sounds like a great suggestion @tlvenn. Do you have any proposal on how to setup/configure a link? Should there be a JS snippet section in the settings for example? How should this snippet be persisted/shared across sessions/projects?

[tlvenn]

Hi @schickling, in my mind, this is defined at integration time so you can pass your composed link to Playground:

ReactDOM.render(<Playground link={myLink} />, document.body)

[schickling]

This makes total sense for code-based usage. However I was also thinking related to the standalone electron/web-app.

[tlvenn]

For the standalone app, I am thinking that custom apollo-links can be packaged as an Electon plugin and be discovered and used by the Playground app.

[schickling]

Sounds good to me. @timsuchanek can you provide some guidance on a potential PR?

[DavidJFelix]

So, I was looking into this a bit. I think following is a good path forwards to building this:

• [x] Add apollo-link and apollo-link-ws to packages.
• [ ] Translate all subscriptions-transport-ws calls into apollo-link-ws calls and use the link client instead of transport directly.
• [x] Allow a createApolloLinkfunction to be passed as a prop. This function should return an ApolloLink class or subclass of it.
• [ ] Move the apollo-link-ws init code into a default function for the createApolloLink prop.

I think we can move on this without an answer for how plugins work. I think whatever the decision is for plugins may change this slightly. Once into apollo-link-ws there can be some extra stories to use apollo-link instead of fetch directly

[schickling]

Hi @DavidJFelix, this sounds like a great next step. Would you be willing to work on a PR for this?

[DavidJFelix]

@schickling I'm doing a little work on it right now. I'll see if I can get a POC and I'll come back if I need any help or guidance.

[DavidJFelix]

My mistake for making promises over the holidays. I'm back. I finally got around to looking at this. I ran into a couple of just general issues with the design but I'm still moving forward. For the sake of transparency, I'm going to open a WIP: PR. Expect rebases on my commits.

[DavidJFelix]

I updated my previous checklist a bit to reflect the changes made so far in the WIP.

What I'm working on now is refactoring the way that the components actually manage the fetcher and call it downstream.

[DavidJFelix]

@tlvenn @schickling can we see if this issue can be closed?

[schickling]

@timsuchanek can you provide some updates?

[DavidJFelix]

@schickling : from the discussion I had with @timsuchanek , he completed my WIP patch, out of band of the pull request. The changes are visible past this commit and are accomplished with the previous 10 or so commits: https://github.com/graphcool/graphql-playground/commit/55fc961a1fbd6c96e7a6d086f22bd058c7930c11

[timsuchanek]

Implemented in latest version.