I do not wish to handle business-logic in Slash Dgraph - I only want Slash Dgraph to act as my persistence layer, not my logic layer.
I wish for my backend to query and mutate the database on behalf of the users; ideally only two system-users have access to the database;
an admin-user (that can update schema, drop all data and such)
a usual client-user (one allowed to query all data as well as mutate all data) (the “client user” is the one “My backend” will authenticate against Slash Dgraph as)
I seem unable to achieve this on Slash Dgraph currently, unless I’m missing something. In other words: Can above be achieved; e.g. have a Slash Dgraph instance that I query using GraphQL and that is only accessible by two users: an admin-user (all operations allowed) and a client-user (only queries and mutations allowed)?
I don’t see why not… create a JWT secret key and lock down all queries and mutations with auth rules that are role based. Then generate a JWT for the admin that has the admin role and one for the https client that has the client role.
Anyone who then tries to use Slash without one of those would get nothing and could do nothing.
Would not a GraphQL endpoint serve a better purpose helping with N+1, overfetching, and underfetching?
Using a REST endpoint layer above Slash GraphQL just seems backwards to me, but it is possible for sure.
if you use DQL, then you can issue client and admin tokens that work exactly as you described
using graphql, you can set up ‘@auth’ rules. You can have a shared secret that your client uses to talk to graphql. Also, you can change auth to be “default closed”, to only allow access to the apis you intend
(coming soon): we are building a way to lock down which operations are allowed without a token. You May then use a client token, similar to method 1 in order to access your api server to server.
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”?
Yes, we use Slash and our app uses the GraphQL endpoint directly. I was also using the DQL endpoint through a lambda function, but I worked around that with dynamically generating some GraphQL for advanced filtering and it respects the auth rules still.
There are so so many different use cases here it is hard to answer anyone specifically. Just like every other API there is more than one way to do it. I have a few recommendations outstanding to add a few features to the auth rules. One of these is being able to query with a rule not related to the data. So one use case would be that when you lit likes it would check a rule that finds your user and checks your account status and then counts how many likes you have if you can add another. For advanced business logic you can still write your own custom queries and mutations and resolve them with DQL, GraphQL, or any other http endpoint. You could spin up your own LAMP server if you wanted to and spin off some business logic towards it. We just did a big chunk of integrating our app with the census API with some scripts to scrape the geo data.
No one service is going to handle 100% of your business logic, but finding one that gives you the tools to handle all of it is up to you.
What seems scarier is a very small 2 man dev team trying to compete with web apps with hundreds of devs and millions of dollars of resources. Users expect our services to be as clean and performant as the FAANG but without even a fraction of .001% of the resources. If I can offload some of this so I don’t have to worry about it, that is what needs to happen. If you want full control though, you can still get it. Use DQL even host Dgraph on your own hardware if you want. Use GraphQL as some boilerplate to get you started and write out all of your own custom resolvers.
There are rising other services that are starting to offer a GraphQL DBaaS with more layers than an onion. They all still do the same thing though and dynamically generate CRUD off from your models and then you still have to add in your business logic.
At the point where you are, I would stop and list out a feature set that is what you are looking for. Decide how much of it you want to do manually yourself and what pieces you want full control over vs dynamic control over automation. And then go from there finding what services fit your needs the best. If you are going to use GraphQL in any way, I highly recommend doing it on a graph database that can model the relationships instead of forcing you to the table or document styles.
I think it is not really about losing a great deal of control but instead gaining a great deal of time and partnering with passionate engineers who have you as the focus of their development.
Last of all, remember that Dgraph’s GraphQL endpoint is not even a year old yet. If they have been able to accomplish this much in a year, what do the next few years have in store?
Again, thank you for taking the time to write up a thorough explanation
These are good points and/or definitely food for thought.
I’ll need to go back to the drawing board and think my stack over again
Yeah I have to agree that, coming from a REST background and having good experiences with AWS API Gateway + Lambdas, that as much as I love Dgraph and Slash GraphQL they feel like a database with a GraphQL interface not an entire backend. Maybe that’s just a bias to what I am familiar with but for now thats how I am using it.
I appreciate it
).