GraphQL Features Excluded from DQL

I’m struggling to understand the interplay between the DQL backend and the GraphQL backend.

GraphQL says it supports @id to mark a field as unique so that mutations cannot create/alter nodes to have the same value. Is this unique checking done in the GraphQL-only code such that this directive will only show up in the GraphQL schema and not the DQL schema? How/where is this being enforced?

I guess my larger question is if there are going to be features that only apply to or get implemented in GraphQL and not in DQL. These could include @id, subscriptions, multiple unique fields or constraints (which is only referenced from the GraphQL docs, not DQL), etc.


@id directive is GraphQL exclusive. But you can create Upsert blocks with some logic to mimic the same behavior.

This is internal code built-in the Dgraph’s GraphQL feature.

Yes and vice-versa. GraphQL is an API Layer language and DQL is a DB language. They are similar, but pretty much hardly you gonna see DQL features in GraphQL Spec. In another hand, some simple features that are not part of a Bussines Logic can be implemented in DQL tho. But each feature needs to have demand(popularity) to gain traction to be implemented.

@freb Check this out for a broad overview of why the DQL and GraphQL differences:

New to Dgraph? DQL vs. GraphQL, Endpoints, Headers, and Schema Translation

Thanks for the resource, @amaster507, that really helps clarify things.

@MichelDiz, framing it as API Layer vs DB language is helpful. I think I just panicked because of a few features that GraphQL has that are missing from DQL and I wondered if DQL support was waning. But I realize now that most of the things I’m doing with DQL aren’t feasible in GraphQL, so I’m content. Though I am a little disappointed some of the features on the horizon for GraphQL (constraints or multi-predicate IDs) won’t see DQL support, at least not on the same timeframe.

Thanks again for the insight.


Yes, I have wondered about the same thing. My biggest irk with dgraph is that there is no unique index, like in most databases. I was hoping the @id directive in GraphQL would be a solution, though as a DQL user this would not apply to us.

Graphql @id directive equivalent in GraphQL± - Users / Dgraph - Discuss Dgraph

@wildan2711 my thoughts exactly. I had just finished implementing a generic approach to unique checking in my application when I stumbled upon the @id directive and related feature issue. I was excited I might get to rip out some code before I realized it was GraphQL only. That lead to me digging through the docs for a few hours before finally posting here.

There really are just a couple of features missing before Dgraph would be the clear default database for every kind of project, at least any project I’m likely to work on. You can see another of my posts for context: Graph Design, Foreign Keys, uid/[uid], and Correctness

For me, the list is actually pretty short, but would include:

  • unique constraints
  • enforce one-to-many relationships, ideally through explicit (and named) reverse relationships that support additions from the parent OR child node (reference).

Other types of generic constraints would also be nice, but aren’t quite as fundamental to keeping the proper shape of your data.

1 Like