Subscriptions-transport-ws: Adding adapters for different websocket libraries e.g. socket.io

[datoml]

Hello everyone.
Lets start with my use case.

Use case
The current implementation uses the websockets/ws package. For my project I wanted to add socket.io to have some kind of fallback to long polling if the websocket connection failed.

So my idea was to extract the current websocket implementation into a wsAdapter. This already works and all tests passed.

My next task would be to add a socket.io adapter.
Before I proceed with this I wanted to ask if somebody already did this?
This is my current fork of the project:
https://github.com/datoml/subscriptions-transport-ws

Some tests are already working for the socket.io adapter.

Maybe some of you have an better idea how to implement this feature.

Edit:
I implemented the socket.io adapter and all tests are passing.

Edit 2:
Removed the old poor server adapter implementation and I am using now the same approach like the client had.
All tests are passing for current implementation and socket.io implemenation.

You are able to use socket.io like this.

import { createServer } from 'http';
import { SubscriptionServer, SocketIOServerAdapter } from 'subscriptions-transport-ws';
import { execute, subscribe } from 'graphql';
import { schema } from './my-schema';

const WS_PORT = 5000;

// Create WebSocket listener server
const websocketServer = createServer((request, response) => {
  response.writeHead(404);
  response.end();
});

// Bind it to port and start listening
websocketServer.listen(WS_PORT, () => console.log(
  `Websocket Server is now running on http://localhost:${WS_PORT}`
));

const subscriptionServer = SubscriptionServer.create(
  {
    schema,
    execute,
    subscribe,
  },
  {
    server: websocketServer,
  },
  SocketIOServerAdapter
);

You are also able to use an existing IO instance.

import { createServer } from 'http';
import { SubscriptionServer, SocketIOServerAdapter } from 'subscriptions-transport-ws';
import { execute, subscribe } from 'graphql';
import { schema } from './my-schema';
import io from './myExistingIOInstance';

const subscriptionServer = SubscriptionServer.create(
  {
    schema,
    execute,
    subscribe,
  },
  {
    ioInstance: io,
  },
  SocketIOServerAdapter
);

The client works the same way.

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

const GRAPHQL_ENDPOINT = 'ws://localhost:3000/graphql';

const client = new SubscriptionClient(GRAPHQL_ENDPOINT, {
  reconnect: true,
}, SocketIOClientAdapter);

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

Would you be interested in adding this feature to this package? Or was the intention only to support websockets/ws?

Greetings

[NeoPhi]

I'm of two minds on this. One is given the name of the package it kind of implies that WebSocket is the transport mechanism so this maybe better as subscriptions-transport-socket.io. On the other hand the bulk of the code will be shared between the different implementations as your diffs indicate. Perhaps this should be restructured like apollo-server in that there is a core package with multiple transport options.

[datoml]

Thank you for your reply. The package name was my concern too.
Because of the minor changes to achieve socket.io a new repo would be a good idea.

[cervajs]

vote for subscriptions-transport which implements fallback methods like long polling, http/2+sse (or engine.io which already solve all the problems where websocket is problematic - https://github.com/socketio/engine.io#goals)

[janecek]

can we made it similar way like relay? https://github.com/relay-tools/relay-subscriptions (they are using socket.io)

[georgyfarniev]

Great idea! I think, socket.io should be supported also, because it very popular and convenient solution. Any updates on this issue?

[datoml]

Great idea! I think, socket.io should be supported also, because it very popular and convenient solution. Any updates on this issue?

Last info I got was that this package is only for native WS. Therefore the name -ws.

[boredland]

It is a shame we have no fallback in place when client/server have issues providing websockets connections.