Enforcing business logic

Users Dgraph
1

Is there a recommended strategy for enforcing business logic at the Dgraph level? This is a general question, but here’s a concrete example:

With this schema:

type House {
    id: ID!
    address: String!
}
    
type Room {
    id: ID!
    house: House
    name: String
}
    
type Door {
    id: ID!
    rooms: [Room]
}

say I want to enforce some requirements on Door.

Specifically a Door should only be added if:

  • rooms is of length 2
  • All rooms for that door are in the same house

The options I can see are:

  • Abuse @auth for this purpose. I think this is a bad idea, but I would like to see a query that can satisfy the requirement, just for my own edification.
  • Refactor the schema somehow. I can see several ways to do this, though none actually solve my problem.
  • Do the checks in application logic. I’m nervous about this because the graphql endpoint is semi-public. Even if my application code is bug-free, somebody might come along and try to run their own query against it.
  • Some directive for enforcing business logic that I’m not aware of.

Are there any recommended best practices? Is there anything on the roadmap?

2

See also the docs on @custom directives. It may help.

Otherwise, you can’t really express this in the type system, as graphql’s typesystem is really not expressive.

3

Ok, that’s about what I expected. I saw an RFC for JS custom directives in the pipeline, and a post here requesting the ability to disable specific CRUD operations (also the comment on the page you linked). With those features implemented, I think it will be sufficient.

I guess it would be possible to disable the default CRUD operations by creating an auth rule that cannot possibly be true, but it would be better if disabled ones didn’t even show up in the schema.