# GraphQL Features Excluded from DQL **URL:** \ **Category:** Dgraph\ **Tags:** dql\ **Created:** [November 25, 2020, 10:35pm UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628 "2020-11-25T22:35:24Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![freb](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/freb/32/2642_2.png) [@freb](https://discuss.dgraph.io/u/freb)\ **Post date:** [November 25, 2020, 10:35pm UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628/1 "2020-11-25T22:35:24Z")
I’m struggling to understand the interplay between the DQL backend and the GraphQL backend. GraphQL says it supports [`@id`](https://dgraph.io/docs/graphql/schema/ids/) 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. ---
**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\ **Post date:** [November 25, 2020, 11:54pm UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628/2 "2020-11-25T23:54:36Z")
> [@freb](#): > > 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? `@id` directive is GraphQL exclusive. But you can create Upsert blocks with some logic to mimic the same behavior. > [@freb](#): > > How/where is this being enforced? This is internal code built-in the Dgraph’s GraphQL feature. > [@freb](#): > > 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. 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. ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [November 26, 2020, 4:42am UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628/3 "2020-11-26T04:42:23Z")
@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](http://discuss.hypermode.com/t/new-to-dgraph-dql-vs-graphql-endpoints-headers-and-schema-translation/10443) ---
**Author:** ![freb](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/freb/32/2642_2.png) [@freb](https://discuss.dgraph.io/u/freb)\ **Post date:** [November 27, 2020, 11:13pm UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628/4 "2020-11-27T23:13:12Z")
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. ---
**Author:** ![wildan2711](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/wildan2711/32/1320_2.png) [@wildan2711](https://discuss.dgraph.io/u/wildan2711)\ **Post date:** [November 28, 2020, 3:51am UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628/5 "2020-11-28T03:51:33Z")
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](http://discuss.hypermode.com/t/graphql-id-directive-equivalent-in-graphql/6027/6) ---
**Author:** ![freb](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/freb/32/2642_2.png) [@freb](https://discuss.dgraph.io/u/freb)\ **Post date:** [November 28, 2020, 5:25am UTC](https://discuss.dgraph.io/t/graphql-features-excluded-from-dql/11628/6 "2020-11-28T05:25:15Z")
@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](http://discuss.hypermode.com/t/graph-design-foreign-keys-uid-uid-and-correctness/8619) 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](http://discuss.hypermode.com/t/json-mutation-cannot-directly-create-reverse-predicate/2787)). Other types of generic constraints would also be nice, but aren’t quite as fundamental to keeping the proper shape of your data.