Is an update using Apollo's SubscriptionClient required?

[bjunc]

Does this library need to be updated to work with the latest version of Apollo? If I use this lib's createNetworkInterface, the console is showing HTTPFetchNetworkInterface is being used, and the URI seems to default to /graphql.

Per the Apollo docs, to use "full websocket" (all queries, mutations, and subscriptions over ws):

import { SubscriptionClient } from 'subscriptions-transport-ws';
import ApolloClient from 'apollo-client';

const GRAPHQL_ENDPOINT = 'ws://localhost:3000/graphql';
const client = new SubscriptionClient(GRAPHQL_ENDPOINT, {
  reconnect: true,
});

const apolloClient = new ApolloClient({
    networkInterface: client,
});

[arjan]

I think this library provides an alternative to subscriptions-transport-ws, in collaboration with absinthe_phoenix it uses phoenix channels to do all graphQL interactions.

[vic]

@bjunc Yes, as noted by @arjan, APW is just a complete alternative to subscriptions-transport-ws, in your code you should use APW's own networkInterface and give it to your ApolloClient upon creation :).

[arjan]

And it works great, by the way, thanks @vic 👍 Must say I have not begun using subscriptions, but doing queries / mutations over WS is already very smooth :-)

[bjunc]

Not sure what about my setup is different than yours @arjan, but I wasn't able to get this lib working. It might have had something to do with #14, not quite sure.

Ultimately, I rolled my own called Phoenix Websocket Network Interface which seems to be more inline with the Apollo recommended interface structure. No subscriptions yet, but I'm using it for queries/mutations over sockets.

@vic if you check mine out, please let me know what you think. I had originally considered forking yours, but it seemed a bit too far off from the structure I was thinking, and I wasn't ready to jump into using Ramda.

[vic]

@bjunc dont think it's something related to #14 will have to fix that anyways, I'm just too far from the computer these days :) So, sorry for not responding as quick as I'd like to.

Sad to hear this lib didn't work for you, I built it just for a customer project a few months ago, and share it with the hope of it being useful to others, if it's not, you are totally free to create your own, fork or otherwise contribute to this one (as I said I'm actually a bit far from keyboard these days, so it'd be wonderful some help handling issues and PRs). And yes, haha, I used ramda mainly because I'm mostly confortable doing Elixir and thinking a bit more functional than normal Js.

How is APW not inline with the apollo recommended interface structure, perhaps you can share some info on how we can improve ?

Cheers !

[bjunc]

No problem about the response delays, totally understandable.

Apollo 1.x convention is to expose a createNetworkInterface method, which then instantiates an NetworkInterface class (I called mine PhoenixWebSocketNetworkInterface). That class exposes query, use (middleware), and useAfter (afterware) methods.

I'm not exactly sure what about APW wasn't working, but I was able to use your socket interfacing logic to get me pointed in the right direction (so thanks!).

All that said, Apollo 2.0 is out now, which changes the convention again. Now, instead of "network interfaces", they use "links". Funny enough, "links" work kind of like plugs. You create a link chain, with each link feeding into the next, before ultimately resolving. I was able to create a new PhoenixWebSocketLink class that uses Observers (instead of Promises). It's working well, but I think it probably deserves its own repo due to it being pretty different than APW (and even the Apollo 1.x network interface I originally created). The only thing I haven't tested is pubsub, but that's not really a priority for me, as I don't really have a good use-case for GraphQL based pubsub (not yet anyway).

What do you think makes the most sense for the community?

[ndarilek]

FWIW, hitting this as well. My network interfaces seem to want to hit http://localhost:3000/graphql when my Phoenix server actually listens on ws://localhost:4000/socket. I think I actually had this working on an earlier version of Apollo, maybe 1.9.1 or something, but 1.9.3 seems to have changed something that has broken this.

Anyhow, no pressure, I'm just adding my voice and experiences in case they help someone else.

[bjunc]

@ndarilek Yeah, that's the same issue I was experiencing. Basically, the network interface is being ignored, and defaulting to a basic HTTP network interface.

Feel free to try my Apollo 1.x based PhoenixWebSocketNetworkInterface. It works for me, in both server (Node.js) and browser environments.

Also, I just pushed a first draft Apollo 2.0 link: PhoenixWebSocketLink. This is also working for me in both server and browser environments. I'll be focusing on this moving forward (as opposed to Apollo 1.x). You can add via npm/yarn: apollo-link-phx-ws.

In neither case am I using subscriptions, but query/mutations are working great.

[vic]

@bjunc Oh so, the interface has changed for apollo 2.0.

It would be nice to state in the README the last apollo version people has been able to get APW to work with. Feel free to send a PR and link to your Apollo 2.0 link if that helps people use the newest version.

[bjunc]

@vic It seems something might have changed with Apollo around 1.9.3, which might be breaking APW even in Apollo 1.9.x. The interface spec definitely changed with Apollo 2.0.

Here's my PhoenixWebSocketLink for Apollo 2.0. Still prototype phase, but it's working for queries / mutations.

[harmon25]

Yea just took a look at Apollo 2.0 yesterday and noticed the changes.
The Apollo team have published an upgrade guide that demonstrates the necessary changes to the instantiation of the client.

@bjunc is on the right track with a new Link interface for a phoenix socket + channel.
I am going to take a look, possibly try it out and fork if I can help!

Have a pretty big react-apollo application - am interested in the potential performance improvements of 2.0

[Yamilquery]

I'm really interesting in your PhoenixWebSocketLink because I need a way to work with Apollo 2.0 subscriptions in my react-native application with react-apollo.

I can't get any way to do that it's works!