I also disagree about @auth being opinionated - I think it is more of a minimal form for defining authorization with nested graph granularity. You can pretty easily use a lambda to enforce higher level auth logic, but you absolutely require something that has @auth’s graph semantics for maximum specificity. It must exist to build secure graph systems.
I think for the rest, the trouble is in thinking about business logic as a sort of ‘query for data and safely merge/sort away from the client to build interesting views’ type of controller. When you use a graph system with granular authorization, you can imagine safely pushing a lot of query specificity to the client, or validation logic to a thin lambda layer. I even do this for a ‘user achievements’ feature. Like…with JWT claims an OAuth client can very easily be prohibited from mutating data beyond a few well-defined relationships. It’s a pretty serious re-thinking of the client/server role, but it’s enabled by the semantics that define authorization…and with the drastically limited attack surface it often cuts out the need for an intermediate server altogether.
Not to say that you don’t want to use servers to intermediate sensitive business logic, perhaps involving complex graph operations or operations on a highly restricted subsets of data…but I don’t see why that’s made harder by the existence of a minimal query api. It feels like I just have solid building blocks. Again, I think most of these Dgraph semantics are just ‘what must exist to make the thing work.’