Support GraphQL over Websocket

:wave: ,

I am the author of graphql-ws and its, brand new, security first, lean, GraphQL over WebSocket Protocol.

The Protocol is aiming to become a part of the GraphQL standard with the help of the foundation’s brilliant GraphQL over HTTP Work Group.

I’d like to hear your opinion on the Protocol and if you would consider supporting it in your awesome Graph database?

If you are interested on reading a short article about the lib and its inception, you can check it out over at The Guild’s blog.

P.S. subscriptions-transport-ws's readme now officially recommends using graphql-ws instead.

MOD EDIT NOTE:
links have now been restored.

5 Likes

I get this error Error during WebSocket handshake: Unexpected response code: 200 so I assume it does not work outside of the box?

The transport Protocol is completely different, so no - it does not work out of the box.

Dgraph uses Apollo’s subscriptions-transport-ws and their deprecated transport Protocol. The new Protocol is a rewrite and the two are not interchangeable.

1 Like

@hardik Any chance of adding this to the Dgraph Roadmap of 2021?

2 Likes

I edited Denis’ post to add links back. It was rather annoying not being able to click on them. @pawan this is something we should look at.

Also I moved this into its own post because this is a feature request.

@jdgamble555 will bring this up in our roadmap discussion. Will keep you posted.

6 Likes

Sounds great. A more general approach than Apollo is certainly appreciated.

GraphQL over WebSockets - The Guild Blog (the-guild.dev)

Thought I mention this link. The also point out a couple of sec issues and shortcomings with the subscriptions-transport-ws protocoll (that you are probably aware of) and that make a compelling argument for me to stay away from it.

Yap, I referenced that blog in my original comment. I am fully aware of everything mentioned in the blog post as I am the one that wrote it (if you were talking to me). :smiley:

1 Like

Consider me ashamed, I am not sure what I was doing just then :sweat_smile: My apologies! Of course you do. Let me make the best of the situation and at least thank you for an excellent library and blog post. :slightly_smiling_face:

1 Like

Absolutely no worries! It happens, just wanted to update you. You’re very welcome, glad my contribution helps people. :smiley:

2 Likes

Here’s a nice comparison article about performance of GraphQL over HTTP vs Websocket (It includes REST as well :sweat_smile: ): OpenShift Console Meets GraphQL Over WebSocket

Nice post, but they have sadly choosen the unmaintained subscriptions-transport-ws protocol and client side lib. :grimacing:

Nevertheless, I’d say the blog’s results wouldnt differ much either way.

@hardik - any news on getting this this year? I think keeping it up to date and secure is always important :slight_smile:

2 Likes

Bumping this topic. Is there a current opinion from the DGraph dev team on the relative prioritization of this?

This has already been mentioned, but it stands out that the library in question is no longer supported. From the message on github repo:

The subscriptions-transport-ws library is not being actively maintained. It is recommended that you use the [graphql-ws](https://github.com/enisdenjo/graphql-ws) library instead. For details read the [GraphQL over WebSockets](https://the-guild.dev/blog/graphql-over-websockets) announcement.

I am tagging along here. An updated WS protocol would be a killer feature for me. I am not comfy with using deprecated apis for this…

3 Likes

any news?

2 Likes

Please don’t forget layer5+ ddos protection
i’ve never used the dgraph subscription feature, and won’t use graphql or graphql websocket, if there is no ddos protection.

Currently I have designed, that my Cloudflare Workers are kind of a middleware between the user and the dgraph DQL/GraphQL API.
Since websockets are a direct connection, this approach wouldn’t work anymore, since i would have to build elixir servers as a new performant middleware, and that’s again overkill

so ddos protection (maybe in cooperation with cloudflare?) would be very cool, to ensure that direct endpoints like the GraphQL endpoint, and more important, the direct GraphQL websocket endpoint, are not abused

maybe check out this Tunnel | Zero Trust App Connector
and this:
https://www.cloudflare.com/website-optimization/web-sockets/

Discord uses Cloudflare to protect its servers. If we want to build with dgraph the second Discord the second Facebook the second instagram, we need ddos protection too
check out:

Is there an issue on Github or a place where I can follow progress?
Thank you.

2 Likes