apollographql / subscriptions-transport-ws

:arrows_clockwise: A WebSocket client + server for GraphQL subscriptions

subscriptions-transport-ws is no longer maintained

subscriptions-transport-ws was the first implementation of a WebSocket-based GraphQL subscriptions transport in TypeScript. It was created in 2016 and was largely unmaintained after 2018.

Users should migrate to graphql-ws, a newer actively-maintained implementation of a similar protocol.

Note that the packages implement distinct protocols, so you must migrate all clients and servers.

If you're using subscriptions with the Apollo platform, the Apollo Server docs show how to use graphql-ws with Apollo Server, Apollo Studio Explorer, Apollo Client Web, Apollo iOS, and Apollo Kotlin. If you have more questions about using graphql-ws with the Apollo platform, file an issue on the corresponding repository or post in the community.

The graphql-ws README shows how to integrate graphql-ws with other software.

If you have not yet migrated off of subscriptions-transport-ws and need to learn more about it, you can read the previous version of this file.

subscriptions-transport-ws's Issues

Pass in a koa server?

From the docs I can see the subscriptionServer takes the standard node http node server.
I'd like to use a koa 2 server instead. Is that possible?

First subscription is never unsubscribed

Because SubscriptionManager returns id = 0 for its first subscription, this check returns false (0) during unsub and the unsub is never done:

if (connectionSubscriptions[subId]) {

HTTP headers

It can be useful to be able to set headers in the client (W3CWebSocket class allows it via constructor fourth parameter), for example to include authentication informations

Anthony.

Add and example of client-server interaction in README

Thanks for putting this together! It's an awesome initiative! 🏆

I find it always very helpful to have a concrete example of client-server interaction for these kind of protocols. (just a JSON message exchange example)

Also, just a minor thing: based on the information provided in the README, it was not immediately clear how type is encoded in the protocol. After looking in the source code I realized that it's just a property of a message itself. Maybe it's worth mentioning it or showing in in some more obvious way in the README?

Remove typings

Like here: kamilkisiela/apollo-angular#94

Ping @kamilkisiela, I don't know if it's a lot of work?

Also, CC @lfittl

Is the reconnect backoff working?

I just upgraded to 0.5.0 to get reconnect working. It seems to really hammer the browser when I kill my graphql server. It gets so bad after a couple minutes that I can't even kill the tab in Chrome.

Is the backoff delay working currently?

Node server keeps crashing repeatedly with "Error: reserved fields must be empty"

This started happening suddenly, and now I can't even get my server back up. It's been a few hours. It just restarts, then immediately crashes. Using 0.5.1 btw.

Any ideas?

Very scary...

DDP Support

Are we looking at DDP support than starting a web socket server on a different port. Adding DDP support will help people like me who want to rely on hosting services like Galaxy and build Apollo server on top of meteor.

abstract SubscriptionClient module to support other backend setups

Would the maintainers be open to a PR that makes the SubscriptionClient module more flexible when using an alternative WebSocket implementation? My use case is as follows: I’ve written a couple of modules for my non-JS backend to handle subscriptions for graphql (they are comparable to the graphql-subscriptions module and graphql-transport-ws server module). Fortunately, the SubscriptionClient works nearly perfectly with this setup, save a couple of API inconsistencies in the WebSocket protocol. I think offering the client-side calling code a few more hooks to modify the SubscriptionClient would make it more compatible with other backend setups.

The problem I’m experiencing is that making a WebSocket connection with my backend requires a slightly different flow than is supported by the SubscriptionClient, I first have to connect via long-polling with socketio, which then immediately gets upgraded to a WebSocket connection. However, the client (the eventual WebSocket connection) does not actually handle the onopen or readyState steps - that is the responsibility of the socket manager, and after both of those checkpoints are passed, all control can be handed over to the WebSocket client.

So what I’m proposing is adding an optional config parameter in the case of using a custom WebSocket implementation, that would be responsible for handling the readyState and onopen checks. If the parameter is passed via the calling code, then the manager gets used in those places, and if it’s not, then the SubscriptionClient can simply behave as it does now.

I have a working version of this based on overriding the connect and sendMessage methods on the SubscriptionClient prototype, but it feels like this should just be an optional parameter to the SubscriptionClient constructor since none of the business logic is actually changed outside of using the manager to set up the connection before handing off control to the web socket.

Make sure this package exports something to add subscriptions to Apollo Client

https://medium.com/apollo-stack/graphql-subscriptions-in-apollo-client-9a2457f015fb#.37xz9hr75

Reported by @mlp5ab from scaphold

Abstract the ws package so we can change it (to use uws instead of ws for example)

I noticed you just recently switched to ws, and I was wondering if it might make sense to switch to uws, which has better performance.

A while ago I forked this module here to switch the websocket library to uws: https://github.com/kesne/subscriptions-transport-uws

Here's a quick post that features a quick overview of the performance benefits of using uws:
https://hackernoon.com/%C2%B5ws-as-your-next-websocket-library-d34209686357#.v5vyqggwq

I needed to install `babel-preset-es2015` to use this

I think we just need to remove the .babelrc from the published package?

Document how to import and initialize

Unit testing failed

Hello the react unit testing failed with this reason.
TypeError: _subscriptionsTransportWs.SubscriptionClient is not a constructor
Any idea guys?

INIT_FAIL message appears to not be properly formatted

Hello,

I am completely new to this project so this may just be the fruit of my incompetence, but it would appear that the SubscriptionClient expect an INIT_FAIL message to contain a payload field, c.f.

subscriptions-transport-ws/src/client.ts

Line 287 in 7dba040

this.connectionCallback(parsedMessage.payload.error);

.

However, it seems that the server sets the error property directly on the message and not under a payload field, c.f.

subscriptions-transport-ws/src/server.ts

Line 161 in 7dba040

return {

This lead to an error when I tried to use connectionCallback.

Furthermore, upon rejection of the connection and if connectionCallback was not specified (to avoid the error), the client kept trying to reconnect without any backoff delay or limit on the number of reconnects.

authorizing subscriptions -- set a default context for client

My goal is simply to validate whether a user is authorized to subscribe to a given channel. For example, if I was creating a group chat app, only members of a group would be able to subscribe to onMessageAdded(groupId: Int!) for that groupId.

From my understanding from digging into the code...

On the server, I can accomplish allowing/denying subscriptions via onSubscribe with a given context:

onSubscribe(parsedMessage, baseParams, connection) {
   // do stuff with baseParams.context to validate subscription
},

On the client, I'm trying to figure out a way to set up a default context for all subscriptions, similar to how networkInterface exposes this with middleware. For example, using networkInterface, we have a redux store that sets a jwt token on authorization headers. We send out queries with auth headers if the jwt is set, and on the server side, we validate the jwt token and pass the validated user into context for the resolvers to consume.

// middleware for requests
networkInterface.use([{
  applyMiddleware(req, next) {
    if (!req.options.headers) {
      req.options.headers = {};
    }

    // get the authentication token from local storage if it exists
    const jwt = store.getState().auth.jwt;
    if (jwt) {
      req.options.headers.authorization = `Bearer ${jwt}`;
    }
    next();
  },
}]);

I'd imagine something similar would/should be possible with SubscriptionManager, where we either (1) apply context via a setupFunction using next or a Promise, or (2) expose some public function that updates the default context for all subscriptions. This seems particularly important if we're using subscribeToMore as I don't see an obvious way to pass context with this call.

Any help or suggestions appreciated!

Integrate with hosted WS service like Pusher.com?

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!

Reconnect when server closes connection?

If the server closes the connection, we don't try to reconnect and resubscribe, which means that any time the server restarts, all active subscriptions get dropped on the floor.

Other websocket engine/server support

In my project i using socket.io with uws engine (it "fastester", because it written with C++), and i using it on csgo.tm, csgo.com, dota2.net, etc. (over 15000 connections at the peak (16 threads CPU, see screenshot below

import http from 'http'
import socketIO from 'socket.io'

const server = http.Server(app)
const io = socketIO(server, {
	serveClient: false,
	wsEngine: 'uws',
	transports: ['websocket', 'polling']
})

How i can connect this engine to the subscriptions-transport-ws?

Inconsistency between implementation / README

For the SUBSCRIPTION_FAIL event, the README says the following:

• errors: Array<Object> : array of errors attributed to the subscription failing on the server
• id: string : subscription ID of the subscription that failed on the server

So I assume, that the message should look like this:

{
  errors: [...],
  id: '...'
}

But the client implementation apparently wants this:

{
  payload: {
    errors: [...],
  },
  id: '...'
}

https://github.com/apollostack/subscriptions-transport-ws/blob/master/src/client.ts#L224

So which way do we want to do it? With or without payload?
Because our backend implementation now implements the first version like specified in the README and I'm wondering why subscriptions-transport-ws is throwing errors.

[0.5.0] Ionic2 and typescript: subscriptions-transport-ws/dist/index.d.ts' is not a module

I am trying to use [email protected] with Ionic2 and typescript, and I keep getting ts error:

File '/home/bojan/www/at4pm/react.at4pm.com/ionic/node_modules/subscriptions-transport-ws/dist/index.d.ts' is not a module.at line 2 col 24

WebSocketFrame is not defined

Hey, after setuping websocket i get this error,
anybody know what i need to change?

Uncaught ReferenceError: WebSocketFrame is not defined

My connection code:

import ApolloClient, { createNetworkInterface, addTypename } from 'apollo-client';

import { Client } from 'subscriptions-transport-ws';
import VueApollo, { addGraphQLSubscriptions } from 'vue-apollo'

const networkInterface = createNetworkInterface({
  uri: 'http://localhost/graphql',
  transportBatching: true,
});

const wsClient = new Client('ws://localhost:3030');

const networkInterfaceWithSubscriptions = addGraphQLSubscriptions(
  networkInterface,
  wsClient,
);

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

Vue.use(VueApollo, {
  apolloClient,
});

and some missing files

 WARNING in ./app/~/websocket/lib/BufferUtil.js                                                                                                         
 Module not found: Error: Cannot resolve 'file' or 'directory' ../build/Release/bufferutil in C:\laragon\www\vet-desktop\app\node_modules\websocket\lib 
  @ ./app/~/websocket/lib/BufferUtil.js 9:19-57                                                                                                         
                                                                                                                                                        
 WARNING in ./app/~/websocket/lib/BufferUtil.js                                                                                                         
 Module not found: Error: Cannot resolve 'file' or 'directory' ../build/default/bufferutil in C:\laragon\www\vet-desktop\app\node_modules\websocket\lib 
  @ ./app/~/websocket/lib/BufferUtil.js 11:19-57                                                                                                        
                                                                                                                                                        
 WARNING in ./app/~/websocket/lib/Validation.js                                                                                                         
 Module not found: Error: Cannot resolve 'file' or 'directory' ../build/Release/validation in C:\laragon\www\vet-desktop\app\node_modules\websocket\lib 
  @ ./app/~/websocket/lib/Validation.js 9:21-59                                                                                                         
                                                                                                                                                        
 WARNING in ./app/~/websocket/lib/Validation.js                                                                                                         
 Module not found: Error: Cannot resolve 'file' or 'directory' ../build/default/validation in C:\laragon\www\vet-desktop\app\node_modules\websocket\lib 
  @ ./app/~/websocket/lib/Validation.js 11:21-59                         

onDisconnect: How to track user?

I'd like to figure out how to run some commands for a specific user when they disconnect. Is there something like a state that is stored to be able to reference within the onDisconnect hook?

Is SUBSCRIPTION_KEEPALIVE needed?

The WebSocketServer implementation being used already has keep alive support build in and it is turned on by default. This is configured via the options passed into the created server:
https://github.com/theturtle32/WebSocket-Node/blob/master/docs/WebSocketServer.md#server-config-options

"Client is not connected to a websocket"

Sorry for the ambiguity, but sometimes I get this error when I start my app.

I am pretty sure I set up most things correctly because I have subscriptions flying all over my app, and it does connect about 90% of the time, but it's a real bummer when it doesn't (nothing realtime works of course) and I have no idea why. :c

Getting error "Must provide schema"

Uncaught Error: Cannot find module "../package.json"

//file: apolloClient.js
import { Client } from 'subscriptions-transport-ws';
import addGraphQLSubscriptions from './helpers/subscriptions';

const wsClient = new Client('ws://localhost:8080');
const networkInterface = createNetworkInterface({
  uri:'/api',
  // opts: {
  //   credentials: 'same-origin',
  // },
  // transportBatching: true,
})

networkInterface.use([authMiddleware])
networkInterface.useAfter([authAfterware, logErrorsAfterware]);

const networkInterfaceWithSubscriptions = addGraphQLSubscriptions(
  networkInterface,
  wsClient,
);

const client = new ApolloClient({
  // networkInterface,
  networkInterface: networkInterfaceWithSubscriptions,
  batchInterval: 10,
  queryDeduplication: true,
  queryTransformer: addTypename,
  dataIdFromObject: (result) => result.id || null
})


//file: ./helpers/subscriptions.js

import { print } from 'graphql-tag/printer';

// quick way to add the subscribe and unsubscribe functions to the network interface
const addGraphQLSubscriptions = (networkInterface, wsClient) => Object.assign(networkInterface, {
  subscribe: (request, handler) => wsClient.subscribe({
    query: print(request.query),
    variables: request.variables,
  }, handler),
  unsubscribe: (id) => {
    wsClient.unsubscribe(id);
  },
});

export default addGraphQLSubscriptions;

Getting Uncaught Error: Cannot find module "../package.json"
Uncaught Error: Cannot find module "../package.json"
    at bundle.e0afedc….js:40432
    at Object.<anonymous> (bundle.e0afedc….js:40432)
    at t (bundle.e0afedc….js:1)
    at Object.<anonymous> (bundle.e0afedc….js:40432)
    at t (bundle.e0afedc….js:1)
    at Object.<anonymous> (bundle.e0afedc….js:40432)
    at t (bundle.e0afedc….js:1)
    at Object.<anonymous> (bundle.e0afedc….js:40432)
    at t (bundle.e0afedc….js:1)
    at Object.<anonymous> (bundle.e0afedc….js:40432)

yarn add subscriptions-transport-ws
yarn build  // i use webpack to bundle my app

as soon as I bundle the app and try to load my page, I start getting this error. anything obvious i'm missing?

Getting error "Must provide schema"

I have a scenario where I can connect, but then when I try to subscribe I get the error "Must provide schema". I will try to drum up a better code sample for this query but wanted to get this question out there - its driving me crazy!

I'm providing a valid schema, and in fact I can perform non-subscription based queries just fine.

I've traced this error to https://github.com/graphql/graphql-js/blob/914dde29098425df45cee95b6feb81b9fed97edb/src/validation/validate.js#L54 and https://github.com/apollostack/graphql-subscriptions/blob/1de0d458f98dca42378673fcbc298bde2d32eacc/src/pubsub.ts#L127 which is confusing me because I use the same valid schema to create a new SubscriptionManager as I do to create my graphql endpoint.

const subscriptionManager = new SubscriptionManager({
  Schema,
  pubsub
});

Does the client application need to be aware of the schema?

Any ideas here?

Split the project in server and client libs

Unsure why the subscriptions bundles both client and server libs. Perhaps splitting it to two projects would be better for re-usability?

Client-side packaging changed in 0.5.2 relative to 0.5.1

Please see this issue:
sysgears/apollo-universal-starter-kit#41

My solution was to force downgrade to 0.5.1. I think something is wrong with "browser" client-side package in 0.5.2

Pass auth token in subscribe

Is there anyway to pass additional information when subscribeing the client to updates?

It seems that there is a context available on the SubscriptionOptions, however, it doesn't appear that the provided context makes it into the params made available to the onSubscribe callback on the SubscriptionServer.

I'd like to provide an authentication token during the subscribe call, to pass to a REST API that utilizes the EventSource/Server-Sent Events Protocol. Is there any interest in exposing this in the API? Or is there possibly another way to accomplish this?

SUBSCRIPTION_READY event

This is just a proposal, but wouldn't it be good to be able to distinguish between the past items recieved on a subscription and the ones that follow the moment of the subscription? A SUBSCRIPTION_READY event emitted between SUBSCRIPTION_DATA events could serve that purpose as it does in DDP.

Handle errors when subscription is active

Basically this: https://github.com/apollostack/subscriptions-transport-ws/blob/master/src/server.ts#L153

I just ran into it when updating GitHunt-React.

Subscription server seem not actually work on my test

Excuse me everybody,
I have tried every method on apollo document and apollo Medium article, but it is not work for me.

Here is my testing code.

It's a simple schema for blog post.
I expect a new post output on console when I excute the createPost mutation, but it show none for me.

// schema.js
import { makeExecutableSchema } from 'graphql-tools';
import { pubsub } from './subscriptions.js';

let mockData = {
  post: [
    {
      title: "Hello",
      content: "Good Morning"
    },
    {
      title: "Something error",
      content: "I can't handle something..."
    }
  ]
};

const typeDefs = `
  type Post {
    title: String!
    content: String
  }
  type Query {
    allPost: [Post]
  }
  type Mutation {
    createPost(data: Postdata): Post
  }
  input Postdata {
    title: String
    content: String
  }
  type Subscription {
    postAdded: Post
  }
  schema {
    query: Query
    mutation: Mutation
    subscription: Subscription
  }
`;

const resolvers = {
  Query: {
    allPost: () => mockData.post
  },
  Mutation: {
    createPost: (_, {data},) => {
      mockData.post.push(data);
      pubsub.publish("signal", data);
      return data;
    }
  },
  Subscription: {
    postAdded: newPost => {
      console.log(newPost);  // Expect for some output, but it never go through this line
      return newPost;
    }
  }
};

export default makeExecutableSchema({
  typeDefs,
  resolvers,
});

// subscription.js
import { PubSub, SubscriptionManager } from 'graphql-subscriptions';
import schema from './schema.js';

const pubsub = new PubSub();

const subscriptionManager = new SubscriptionManager({
  schema,
  pubsub,
  setupFunctions: {
    postAdded: () => ({  // Mapping postAdded subscript to signal channel
      signal: ()=>true
    })
  }
});

export { pubsub, subscriptionManager };

// index.js
import express from 'express';
import bodyParser from 'body-parser';
import { graphqlExpress, graphiqlExpress } from 'graphql-server-express';
import { SubscriptionServer } from 'subscriptions-transport-ws';
import { createServer } from 'http';
import { subscriptionManager } from './subscriptions.js';
import schema from './schema.js';
const PORT = 3000;
var app = express();

const GraphQLOptions = () => ({
  schema
});

app.use('/graphql', bodyParser.json(), graphqlExpress(GraphQLOptions));

app.use('/graphiql', graphiqlExpress({
  endpointURL: '/graphql',
}));

const server = createServer(app);
server.listen(PORT, () => {
  new SubscriptionServer({
    subscriptionManager: subscriptionManager,
  }, {
    server: server,
    path: '/subscriptions',
  });
});

Use ws also for regular queries

Since you are setting up the websocket anyway, you can use that channel to request normal queries as well, leading to less overhead (no TCP setup, no session lookup).

Question - purpose of context.

Hi,
This is more of a functionality question, but how does exactly context work? I thought that when I set context on client, which is then send to server, Subscription server will pass it to the subscriptionManager. But when I looked at the code and also consoled out context, it was always an empty object. So what exactly is the purpose of it? Or is it expected to be altered in custom onSubscribe function?

server crash with bad client

The server does not correctly handle a client that sends a bad protocol resulting in a server crash. Using GitHunt-API as an example:

GitHunt-API/node_modules/websocket/lib/WebSocketRequest.js:289
            throw new Error('Specified protocol was not requested by the client.');
            ^

Error: Specified protocol was not requested by the client.
    at WebSocketRequest.accept (GitHunt-API/node_modules/websocket/lib/WebSocketRequest.js:289:19)

Testing using the wscat npm module. After launching the server run: wscat -c ws://localhost:8080

Issue looks to be that https://github.com/apollostack/subscriptions-transport-ws/blob/master/src/server.ts#L76 blindly accepts all clients.

Cannot read property 'handler' of undefined at WebSocket.client.onmessage

I get the error Cannot read property 'handler' of undefined at WebSocket.client.onmessage when I run this code:

import ApolloClient, { createNetworkInterface } from 'apollo-client';

import {SubscriptionClient, addGraphQLSubscriptions} from 'subscriptions-transport-ws';
//import { Client } from 'subscriptions-transport-ws';

// creates a subscription ready Apollo Client instance
// Note that scaphldUrl expects the url without the http:// or wss://
function makeApolloClient(scapholdUrl) {
  const graphqlUrl = `https://${scapholdUrl}`;
  const websocketUrl = `wss://${scapholdUrl}`;

  // Create regular NetworkInterface by using apollo-client's API:
  const networkInterface = createNetworkInterface({uri: graphqlUrl});
  console.log("websocketUrl", websocketUrl)
  // Create WebSocket client
  const wsClient = new SubscriptionClient(websocketUrl, {
      reconnect: true,
      connectionParams: {
          // Pass any arguments you want for initialization
      }
  });
//.......
}

Subscriptions seems to be working (my list of items gets longer when I insert items in an other browser)

Is this error important ?

Change README to emphasize standalone usage rather than Apollo Client

This package can be used by anyone in the GraphQL community even if they aren't interested in using Apollo Client to cache their results. We should have both examples and lead with the generic one.

Try to understand the error

Hello all,
I follow the readme file to subscription. but I keep getting the "Invalid message type. Message type must be subscription_startorsubscription_end."

Am I missing any thing here? Did we have some really simple example just subscription server side config change?

Thanks so much

No license

Can PR the license additions if you tell which one you'd like :)

Missing EventEmitter on recent RCs of @angular/cli

An error:

eventemitter3_1.EventEmitter is not a constructor

It happens inside a project that has been created by @angular/cli@^1.0.0-rc.1.

---

In client.ts, we've got this:

import { EventEmitter } from 'eventemitter3';

In eventemitter3/index.js:

EventEmitter.EventEmitter = EventEmitter;
export default EventEmitter;

Webpack creates a bundle file that contains that:

var _eventemitter3 = require('eventemitter3');

// inside SubscriptionClient of `subscriptions-transport-ws`

this.eventEmitter = new _eventemitter3.EventEmitter();

The thing is, _eventemitter3 has no EventEmitter property assigned. It's missing...

console.log(_eventemitter3); // EventEmitter class
console.log(_eventemitter3.EventEmitter); // undefined

When you look up for the eventemitter3 package inside the bundle file, there's no EventEmitter.EventEmitter but there's another property available that has been assigned the same way (EventEmitter.prefixed). It somehow removes the assignment from the code.

Weird...

npm package index.js/index.ts import and export Client instead of SubscriptionClient

import Client from './client';
import SubscriptionServer from './server';
export { SubscriptionServer, Client };

should be:

import { SubscriptionClient } from './client';
import { SubscriptionServer } from './server';
export { SubscriptionServer, Client };

Provide a browser bundle suitable for direct browser consumption

Noticed the client uses require which makes sense if one uses it on node or via browserify/build tools. What if we also expose a browser bundle for the client which already ships everything packaged so that it's possible to reference the library directly via https://unpkg.com?

Middleware for connection params

Is there a middleware for connection params, similar to the one used for apollo-client? Typically you don't have the authentication token ready when setting up the subscription client. So if you want to require a specific token as the authorization header that the user can only obtain after logging in, how could we set that up?

Intermittent test/CI fail - Client should throw an error when the susbcription times out

1) Client should throw an error when the susbcription times out:
     Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.
      at Timeout.<anonymous> (/home/travis/build/apollostack/subscriptions-transport-ws/node_modules/mocha/lib/runnable.js:230:19)
      at tryOnTimeout (timers.js:232:11)
      at Timer.listOnTimeout (timers.js:202:5)

CI and local tests fail regularly on this specific test. Maybe we're a bit tight in authorised timeout in the tests.

Why client connect states `graphql-subscriptions` as protocol

Looking at https://github.com/apollostack/subscriptions-transport-ws/blob/master/src/client.ts#L184
once the connection is opened it immediately set this header Sec-WebSocket-Protocol:graphql-subscriptions. Is this strictly needed? I'd imagine there could be different protocols/commands running over a single websocket transport (queries, mutations.. other.)

Publish to single client

Is it possible to publish the result of a subscription to a single client matching a defined criteria?

For example, say a user has subscribed to user account modifications and I want the WS clients/connections for this user to be notified every time a change to his account occurs.

Client hooks for onConnect and onDisconnect?

Knowing when the websocket connection connects and disconnects could be important to showing certain UIs to users. Do you think it would be reasonable to add an onConnect and onDisconnect hook to the client constructor so that you can roughly determine the connection state?

FWIW I implemented a super simple version of this (along with a keepAlive timeout) in my fork: master...kesne:master

subscribeToMore: Unhandled GraphQL subscription error: Cannot read property 'subscribe' of undefined

I am using the following setup with react-native:

"subscriptions-transport-ws": "^0.5.5-alpha.0"
"apollo-client": "1.0.0-rc.6"
"react-apollo": "1.0.0-rc.3"

When calling subscribeToMore I will always get the following error:

Cannot read property 'subscribe' of  undefined

Also the apolloClient instance has no method called subscribeToMore, so the example in the readme does not work.