Following on from
I’m able to get a connection from urql to dgraph.
But my question is. Is it possible to do queries and mutations from websockets?
Is it possible?
I ask due to getting undefined from my hooks and in the network tab for websockets:
{"type":"connection_init","payload":{}}
Do you mean DQL or GraphQL? I’m not 100% sure, but GraphQL is over WS. For example, subscriptions, it has to be via WebSocket. And Dgraph’s GraphQL feature has subscriptions.
I mean GraphQL.
Subscriptions is a settled matter, hence why the title and question (here) doesn’t mention it.
Paul,
Subscribing to a mutation does not make sense. You subscribe to changes in a database. A mutation is made to be a one time transaction, so you use a Promise. You change something, and get the results back from that re-fetch query immediately. There is no such thing as a mutation that would keep changing. A normal query is used in the same manor. You send the query to the api using a promise, and you get back the results immediately. Like the REST api, sending a request to your api endpoint using some kind of fetch, will return your data immediately one time. This is just how fetch works, specifically using a graphql endpoint with the http (https for secure) protocol adhering to the graphql spec.
Subscribing to a query, however, uses the ws (wss for secure) protocol to create a TCP connection. There is no such thing as a subscribable mutation. In fact, you subscribe to a query via the GraphQl spec by literally leaving the query the same, and replacing the word “query” with the word “subscription.” Any changes in your query will be resent to your secure client in real time. Because this is a feed of data, you use observables instead of promises on your client to receive the data. URQL uses WONKA, but you could also use RXJS. This depends on your framework and use case, and they can be translated using the standard Observable spec.
In sum, you cannot subscribe to a mutation, as that is not how neither WS protocol, nor GraphQL protocol work. It also does not make sense.
It should also be noted that there are two known implementations of the Websocket Protocol:
DGraph still uses the OLD implementation of Subscriptions that is no longer being maintained. The creator of graphql-ws has put in a feature request for Dgraph to change to graphql over websocket, but it is something that was never added to the feature list. Considering it contains security issues, I think it is more of a security problem than a feature. However, it is worth noting that it MAY (I am not sure) break the current websocket implementations that DGraph uses.
J
I don’t wish to be rude. But you have just constructed a straw man and attacked it.
I never mentioned subscriptions. The original question had nothing to do with subscriptions.
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 doubt the facility exists right now. So let me be clear.
I would like to see in a future iteration of Dgraph. That it is websocket first. Especially looking at the future with web3 technologies.
Why use HTTP when websocket can be used?
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?
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.
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.
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.
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.
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.
Is there a particular exotic feature that you would like to see? Maybe we could start there.
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
hahaha… 
I can feel your angry.