Beginner question: Connecting to Dgraph directly from the front-end

@minitauros, I think you are exactly where I was when I started. What is DQL? How is that different from GraphQL? Why multiple endpoints? How to do authentication? How to hide sensitive data with authorization? And so many more…

I cannot stress enough the importance of this post:

That will help break some of the icy waters as you find these new terms such as DQL thrown about with not much clarification. Sorry, it is hard for us sometimes to remember what we didn’t know at one time ourselves.

Yes! I would, I did, and I will again! I replaced a growing namespace of 500+ databases with a single Dgraph’s Slash GraphQL instance.

In the perfect Dgraph setup, you would probably have GraphQL @auth rules publicly allowing the public data or user’s data such as their private to dos. This way you can actually build in the administration of your app on the same front end as your app. This takes away much of the need for management at the back end. You could run GraphQL queries/mutations directly through Slash UI or any other GraphQL tool to do ad hoc administration access. I myself have written a few admin scripts that we use to clean up data that most of them all work in pure GraphQL. The greatest thing about Dgraph is that the GraphQL is not an API layer, but it is the core functions of the database. So what do you need DQL for? DQL is similar to the GraphQL syntax but it has been extended for use cases such as upserts, rdf triples mutations, and variable passing blocks (stuff that GraphQL cannot do yet by spec). You may down the road run into something that cannot be done yet in GraphQL and then I would recommend to be ready to learn DQL. until then, I would jus stick to GraphQL. One example is that I needed to change a username that is tied to a field that is tied to the @id predicate. That was not possible in GraphQL, but a pretty simple feat in DQL. DQL, is really just a way to bypass the auth rules of GraphQL and use the extended functionality. It is powerful and IMO should not be public facing or tied to a front end like react. I would be very careful to keep DQL endpoint a secret. With the poor man’s auth on the DQL endpoint, you don’t have to worry about that much anymore, and still have access to it when you need it. Pretty sweet stuff if you ask me.

Afterthought:

I think the main understanding that will answer this question in full is that even if someone knows about the schema, if they do not meet the auth rules for those parts of the schema they are disallowed from doing anything with that. They can only create, read, update, and delete what you say they can in the rules. Before you go to production with any Slash GraphQL instance, make sure you have locked down your auth rules correctly and have tested them.