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?