Confused about GraphQL vs DQL client usage

@amaster507

In this post,

http://discuss.dgraph.io/t/dql-with-apollo-client/16070/2

you said

“Are you using DQL from a client? Like an actual client on the web and not another backend?
DQL should only be Server → Dgraph as it is very susceptible to injection”

But that seems to contradict “HTTP Client A Dgraph client implementation for JavaScript using HTTP. It supports both BROWSER and Node.js environments.” This is from the docs, Dgraph Query Language > Client Libraries > JavaScript > HTTP Client
https://dgraph.io/docs/clients/javascript/http/
(Italics mine)

It seems to contradict this too:

https://dgraph.io/docs/graphql/custom/dql/

If you’re not supposed to use DQL from a client, but you ARE supposed to use GraphQL from a client, why can you use DQL from inside GraphQL?

Does it have to do with the DQL query being defined as a type in the Schema?

Does client not always mean browser?

Also in this blog post: https://dgraph.io/blog/post/graphql-vs-dql/

“When not to use DQL

  • When the client cannot be trusted, such as with javascript applications that run in user environments.
  • When you don’t want to give your clients access to drop your database or alter your schema.”

The HTTP client runs in the browser, which means user environments, does it not?

1 Like

First, thank you for taking the time to read what I have already written :slight_smile:

Well, just because you can do something, doesn’t mean that you should. :wink:

A client could be another controlled environment such as a controlled Node server, or serverless Lambda-like controlled environment or a uncontrolled Browser.

Next.JS would be an example where you could use the DQL client on the server side with SSR, but to be safe, you should not use it directly inside Client Side rendered components and hooks.

There are still gotchas here to be understood and mitigated, but for the most part, this is a more controlled method because of the strict typing of GraphQL, it only lets you run the DQL that you specifically pre-allow in the schema or a custom lambda.

Just because it is HTTP(S) does not mean it is specifically browser (unsecure) based. You could have a server using HTTP(S) to communicate with other servers all inside a controlled environment and even inside a VPN and use HTTP in a secure fashion. HTTP(S) is just the protocol and not necessarily means it is end user directly.

This is the reason I tried to clarify with:


If a user wanted to run a browser based application and allow the user to have full control to the BE with very limited Auth, then they could run a direct connection from the Browser to the DQL endpoint of Dgraph. Just like they could do this with most any other database query language like SQL, Cypher, etc. But again, just because you can does not mean that you should. Security can be as strict as you can possibly make it or as lax as you dare to allow.

2 Likes

Thanks for your reply! I’m thinking about it.

Ah, I see.

Okay, that makes sense. I don’t really have to great of a handle on the different ways to do backend things so I’ll have to read up I guess.

1 Like