Subscriptions-transport-ws: Integrate with hosted WS service like Pusher.com?

[TSMMark]

Is this possible? If so is it documented? I am exploring Apollo and considering introducing it into our React Native app at Vydia. Any information on this would be much appreciated. Thank you!

[helfer]

Where would you consume the pusher messages? On the server essentially as an alternate PubSub system? If so, you could easily build another SubscriptionManager (which is in the graphql-subscriptions package).

If you want to use pusher as a transport from server to client, it wouldn't be graphql subscriptions any more, so you'd be talking about an entirely different architecture that would replace GraphQL subscriptions.

[TSMMark]

The client would subscribe to pusher messages, and the server would publish them.

Maybe I'm missing some things, but why do you say "it wouldn't be graphql subscriptions any more"? I was reading graphql-subscriptions docs and it is claims:

PubSub can be easily replaced, for example with https://github.com/davidyaha/graphql-redis-subscriptions

But if we want to use Pusher as our websocket layer, why is that not compatible?

[davidyaha]

@TSMMark As you say, it's not just pubsub engine that you need change here, but the transport.
graphql-subscriptions is the package that runs the graphql query on each event of every subscription, so actually, I think using this package and replacing both the engine and the transport (client and server) with Pusher.com is possible and could even be a very cool package for anyone not looking to maintain it's own PubSub.

Then again, I would consider that only if you already use graphql and apollo as the state manager.
You would need to implement the subscribe and publish methods on the client's network interface, and also implement your own PubSub Engine, just like I did for redis.

You will gain apollo client normalized store and other features, and a pretty flexible filtering using the subscription's query part.

[TSMMark]

@davidyaha thanks for your valuable insight! When you say,

I would consider that only if you already use graphql and apollo as the state manager.

I'm curious what you would consider if we were already using graphql + redux + react, but not Apollo.

[davidyaha]

Well if you already use redux and react it's a shame not to use apollo :) I was at the exact same place (minus the graphql integration) a few months ago.

I think you should do that and get rid of you own state management logic so you could focus on building the app. Or even better, use apollo, and see if it answers your own use case. We might get some pretty sweet PR's, so on the next app one of us will develop, we could have all that fully battle tested framework that will make our lives easier (Which I know some of us will not agree about it being a good thing ]:-) )

[TSMMark]

@davidyaha I completely agree with your first sentence. We're still very early into this app so we can still pivot into something like Apollo quite easily.

[lorensr]

See #80