HI @amaster507!
First of all thank you for taking the time to reply 
I appreciate it
For the following, please consider me
- a “beginner” into GraphQL and
- coming from a “client <–HTTP REST–> backend ↔ database” way of thinking
It would indeed, but I face some other challenges with this approach. See below.
I fear that there’s something fundamental I’m missing; applications that use Dgraph…do they really interact with Dgraph directly?
I have a hard time believing that (but maybe I’m simply stuck in my ways of thinking 
).
Questions/challenges that come to my mind immediately are:
- How would one deal with rate limiting / throttling users’ access to the Dgraph endpoint?
- More complex business-logic - how is that “respected” when users can query the database directly…? For instance, consider the example of the “free tier” of a dating app, such as Tinder, where the “free tier” only allows you a certain number of daily likes. How would you implement that in Dgraph?
- How do you prevent the insertion of invalid data? By “invalid” I don’t mean data that does not respect the database schema, but data that is invalid in terms of business-logic; for instance say inputting an invalid social-security number or some other, external identifier that a intermediate backend (in the HTTP REST paradigm) would be able to verify exists, before insertion into the database.
- A general thought: Not handling users’ access to the database, it seems to me as if one - being a developer - looses a great deal of control/idea of “what’s going on” as requests does not go through your backend. Doesn’t developers find this “scary”?