Query, Mutate possible over websockets?

[jdgamble555 (Jonathan Gamble)]

@Paul

I don’t wish to be rude. But you have just constructed a straw man and attacked it.

Hi Paul, I’m not having an argument at all, but simply explaining how these technologies work, specifically the protocols and specifications. Perhaps I’m still not understanding your question, so I will try and elaborate.

@Paul

I never mentioned subscriptions. The original question had nothing to do with subscriptions.

So by design, you use subscriptions in GraphQL to call websockets. You could theoretically call socket.io as well, but the word “subscription” denotes some kind of socket or persistent connection, which will use the TCP protocol under the hood. Typically you have sockets under the hood with subscriptions, not the other way around.

@Paul

That should be absolutely obvious and I’m sorry that it is not. Maybe because the conventional thinking is too narrow [with established users of dgraph] and I, still being new to Dgraph can think more outside of the box.

I agree what you’re asking is non-conventional. I am a firm believer that we use and create technologies to help solve our problems, we don’t use and create technologies, and then find a problem it solves.

@Paul

That it is websocket first. Especially looking at the future with web3 technologies.

I personally believe that Web3 is a very far away technology. There is no consensus for how IPFS, blockchain, decentralized ids, etc. will fit into the future. There are many computer scientists who believe Web3 cannot be done in the way many people envision, all which envision differently. There are many security issues, and Web3 is arguably not even decentralized at all. I would be happy to discuss the decentralized web on an off-topic post, as it is a particular fascination of mine. I believe it will be up to companies to create their own envision how how the future internet will work.

@Paul

Why use HTTP when websocket can be used?

Because that is not how the architecture is meant to work, and it is not always better. Queries and Mutations are stateless actions and more critical. You don’t want to create a persistent connection on stateless actions. The packet sizes and latency differ between both websockets and http connections. Websockets are also going to be harder on your database, which is harder on your server, which costs money and resources. Generally speaking, you want to pick and choose when to use Subscriptions (which use websockets in DGraph’s case) to save resources. Usually this involves a messaging feature or some kind of notifications.

@Paul

Note to the devs, there is an awesome library called centrifugo it’s written in go as well. Perhaps a possibility exists where a more extensive websocket server exists within Dgraph allowing for more exotic features?

Is there a particular exotic feature that you would like to see? Maybe we could start there.

@Paul

I mean GraphQL.

@Paul

I doubt the facility exists right now. So let me be clear.

To answer your question at hand, I believe it COULD be done. I believe, however, you would have to break the GraphQL spec. The link you provided above shows how the client side can direct URQL to the correct protocol whether or not it is a subscription. I don’t think this is what you were asking, as what you were asking is very unconventional as you said. I don’t believe Apollo nor URQL is meant to run the http part of the connection using a persistent connection. You could write a custom connection to send mutations and queries via the websocket protocol, but the question is whether or not you SHOULD, and which protocols and standards you would be breaking to accomplish this.

J