Santa wish list for Dgraph in 2021

Re-indexing already allows a “background” option. Correct me if I’m wrong, @ibrahim

1 Like

default values support for graphql. Right now you can do it with lambdas but it’s a pretty crazy thing to do.


Multi Tenancy
Integration with Kafka
these are more important for me. and the system stability is also important.

Ahhh… Could be a docs issue. I’d have to find the part that led me to that (or… That I misread). Trying to find it again, I see some changes in 1.12, and MR#4819 with bg index.

My Santa came early. …last spring lol.

default values with a directive would be much better. Right now a default value with lambda requires a custom mutation which then you lose the benefit of creating deeply nested data in a single mutation. You couldn’t for instance create a author with a post and have a default value on the post unless now you created two lambda mutations, one for just a new post and one for a new post with author.

That’s correct.

@trka is what you’re looking for :slight_smile:

1 Like

Deep Patch mutations.


1 Like

Ability to do atomic mutations without DQL


GraphQL has too many restrictions. I hope DQL can be more powerful and compete with the top graph database.

1 Like
  1. I hope there can be synchronous transactions, which can directly sense that the transaction has been completed.

  2. More detailed log information, such as downtime log.

  3. Java connection management: after the node is down, the connection of the node will be skipped. At the same time, the connection will be restored after the node is restored.

  4. The cluster can have higher stability for concurrent requests. Now there will be node downtime and connection exception.

One more for me: Ratel… needs love.

1 Like

I would love to see in Slash GraphQL

  • Support for more AWS regions, at least add in US East
  • AWS VPC Peering, the Mongodb Atlas service does this very well

For Slash GraphQL

  • Relationships & auth builder in visual schema builder
  • Data Explorer - for quick data inspection & debugging
  • Environment variables for lambdas
  • Default values in schema

Unique indexes for DQL. If I’ve created a schema using graphql and specified that a specific field is unique, e.g. slug: String! @id, then it shouldn’t be possible to create a new node of that dgraph.type with duplicate value assigned to that field/predicate.

Would be happy if Dgraph team announced that they are working on an offline-sync solution for mobile. What would make sense to me is to create a fork of MongoDB’s (Apache-licensed) Realm database, and then create some extensions for it so it can sync directly Dgraph Cloud. The only realistic alternative right now seems to be AWS App Sync which is super complex and involves creating a dedicated graphql API just for the mobile clients.

There is an initiative from the community for this. IHMO I think that offline support or even off in mobile is truly a complex situation. In terms of sync, overcopying and security. I don’t see Dgraph working on it on mid term.

You can use the Upsert Block logic to have this. Or even use the GraphQL feature. It is supported there.

Everything has it costs. No magic comes without pain. Something needs to be sacrificed :stuck_out_tongue: I particularly prefer to stay on a consolidated model than invent the wheel and have an ultra-complex model that can lead to problems getting new engineers to maintain it. That’s my 2 cents if I would be a manager or even a CEO in a small startup. “Keep it simple”.

Before diving into some critical feedback, let me preface by saying dgraph is a very exciting database and, in general, I really love the (substantial) work so far.

I’ve been working on learning dgraph off-and-on for the past few weeks and so far I’ve found the documentation to be…lacking. Part of it is that I, personally, find DQL to be non-intuitive so that means I’m relying on the docs much more than I would when writing, say, Neo4j’s Cypher (which I generally find to be intuitive) or Firebase’s Firestore (which, admittedly, is a much less powerful query language than DQL but is also intuitive for me). But separately I do think the documentation just isn’t well thought out at this point.

This issue is a good example both because the “correct” DQL is highly counterintuitive to me and also because I don’t think that using DQL and GraphQL APIs together is well described in the docs (which apparently involves special considerations).

  • Edit: I found that there is a section of the docs that describe using DQL and GraphQL together, but it’s called “GraphQL on Existing Dgraph”. What about someone who’s creating a new instance of dgraph that uses both DQL and GraphQL? So long as there are things you can only do with one API vs the other, I expect many apps will use both APIs. This is a pretty direct example of poor documentation. For example, renaming this section to “Using both DQL and GraphQL” would be an improvement and linking to this section from both the GraphQL and DQL docs, since you can’t predict where someone will start, would be another improvement (not sure why this concept is only mentioned in the GraphQL section–I generally find the GraphQL section to be more intuitive so I’ve been spending most of my time in the DQL section).

Considering how much time and energy must have been spent to getting dgraph to this point, it really seems like you’re shooting yourself in the foot by not spending more time on the documentation.

As another example, I’d love to never need to learn RDF when learning dgraph. I’m already spending time learning a new, proprietary query language (DQL), I’d rather just stick with JSON since I’m not already familiar with RDF. And dgraph seems to support my choice to do this. Unfortunately, the documentation doesn’t support this choice as the docs often default to RDF and provide examples both in RDF and JSON formats. A better experience would be if there was just a toggle in the docs to show every example using JSON or show every example using RDF. This would be similar to how many Google APIs (here’s a random example) let you choose which programing language you want to view examples in (e.g. python, Javascript, Go, etc).

As another example, and this is opinion, but I’m really not liking the use of the term “predicate” in dgraph. This could be because my background is with Javascript and Ruby and when I typically see the use of “predicate” it’s referring to a boolean function, but in general I would find replacing the word “predicate” in the docs with the word “property” to be much more intuitive. I think a node is most intuitively thought of as an object or a document, both of which have properties. This would also better reflect the terminology used by other graph and nosql databases, as well as the terminology of the (theoretically upcoming) GQL standard. Dgraph seems to be an outlier here, but perhaps there is a popular precedent I’m not aware of (and obviously this is just one opinion).

Similarly, calling edge properties “facets” instead of the more obvious “edge property” or “edge attribute” doesn’t seem like the best choice. I realize that edge properties have subtle differences vs node properties, but in this case I don’t think that justifies giving them a different, less intuitive name. Any time you find yourself giving something a name and then explaining what that name means to the reader, you should pause and ask yourself, “Why don’t we just drop the proprietary name and ‘use the intuitive explanation’ instead?” Some times there are reasons to rename something, but I don’t think “facets” reaches that bar.

Anyway, obviously there’s a lot of opinion here and again, despite frustrations I do really appreciate all the work that has gone into dgraph.

As a random musing: it just occurred to me that I’ve never heard of a development team practicing documentation first development (and I’ve never done this myself). I wonder how a project would turn out if you tried writing the docs first, as you would like to be able to describe the API, and then tried making the app. This is basically what UI driven apps do, when a designer designs the UX first and then codes the app to mimic that UX.


We are well into 21 but wanted to pile on my requests for even better search functionality.