What is Dgraph lacking?

In my opinion, the entire bet on graphql is cool but if it doesn’t take over the API standard then pretty soon most people would have a high entry barrier for using dgraph and its goodness like cluster transactions and performance scaling and the smooth smooth modelling may remain unutilized. I am personally graphql biased but still in projects where there is no graphql at all it feels like bringing a cannon to a knife fight to get dgraph (I do it anyway cause I love modeling data on dgraph schema, lol).

I should probably not suggest solutions but I would like the graphql and dgraph database to be separated (somehow). And I don’t mean just the graphql serving but also to support another language (like gremlin) or ur own custom SQLesque graph DB language. So that people who don’t buy into graphql can be comfortable with dgraph.
And on the other hand, I do like the graphql serving features and it’s so good to just give schema and have such a good API ready with the knowledge that it’s backed by a graph db with infinite flexibility.
But it would be even better if this was separated into like nodejs or go or rust server(embeddable runtime? library?) so that it can be hosted separately, modified as we like, and more generally have an ecosystem rising on it so that we can be even lazier and pull plugins to, let’s say, add events to subscriptions from kafka or nats source, or maybe to do the whole jwt thing but with infinite flexibility or it could be file uploads streaming to S3. But still have the super tight integration with dgraph. Maybe a graphql to dql compiler/code gen so we get the code and just modify the code as we like. without learning the dgraph specific things.
Essentially it’s all about building something on which an ecosystem can thrive. the current solution with lambda works but has some learning involved and an ecosystem wont start on it.

  1. Also collections probably? more json focus ? multi model like feel?
  2. Schemas are good but currently, dgraph is for rapid iterations so more focus on schemaless dev?
  3. expand to work without schema
  4. tools to gen txn that move data when schema is modified
  5. multiple databases in single backend?
  6. typescript binding for dql client as well so responses are typed?
  7. customisable full text
  8. ability to add custom indexes
  9. pregel like compute system (with some common targets already implemented)
  10. rewrite in rust to brag on performance (just a rust fan boi pls don’t kill me)
  11. OLAP mode / integration with olap tools
1 Like