Nice! It's been a few years but what I remember is that if I ever had a chance to ask, I was going to ask this: What was the problem that calling what laymen call attributes/properties Predicates solved, are they just attributes, and is there some other mathematical property of DGraph predicates that makes them different from normal attributes that a user should know?
Literally every dgraph user must necessarily know the answer to that already, or maybe they just mentally black box it and work around it, but at the time, my impression was non-users don't know this, and if I'm adopting a whole new taxonomy I need extra incentives to know it's worth while. It's probably an excellent and even superior technology, but what read as auteurism in the product at the time made me reconsider how much time I wanted to invest before encountering another one.
Anyway, coming from being a Cypher user, the learning curve for the use case of "I want to create nodes of different types with attributes, with relationships of types with attrbites, then CRUD them and verticies with a Flask app" felt a bit steep after that.
SQLite would do the trick, but I wanted consistency from my business logic to a grammar, to a data model. It's very easy to encounter graphs and just think we're not smart enough for them or our problem isn't graphy enough, but given the ease with which I could encode a grammer into cypher, I reluctantly gave up on dgraph. That said, I'm not a gremlin/tinkerpop fan either, as from a top-down user use case, it wasn't satisfying either.
DGraph has a lot of users and customers who love your product and the smartest people I knew recommended it to me, so my issues might not register, but there were a few experiences going through the tutorials that made me wary I was sinking costs into it relative to my use case, e.g. I have 1 week to build a PoC Flask app with a graph on the back end, and then scale it if the customer cares. That's what I used Neo for, and didn't use dgraph for, even though I figured I'd hire developers to rewrite it for dgraph if it got off the ground.
Anyway, long way round, but I'm a long time believer and user of graph techs and want everyone in that market to succeed.
Literally every dgraph user must necessarily know the answer to that already, or maybe they just mentally black box it and work around it, but at the time, my impression was non-users don't know this, and if I'm adopting a whole new taxonomy I need extra incentives to know it's worth while. It's probably an excellent and even superior technology, but what read as auteurism in the product at the time made me reconsider how much time I wanted to invest before encountering another one.
Anyway, coming from being a Cypher user, the learning curve for the use case of "I want to create nodes of different types with attributes, with relationships of types with attrbites, then CRUD them and verticies with a Flask app" felt a bit steep after that.
SQLite would do the trick, but I wanted consistency from my business logic to a grammar, to a data model. It's very easy to encounter graphs and just think we're not smart enough for them or our problem isn't graphy enough, but given the ease with which I could encode a grammer into cypher, I reluctantly gave up on dgraph. That said, I'm not a gremlin/tinkerpop fan either, as from a top-down user use case, it wasn't satisfying either.
DGraph has a lot of users and customers who love your product and the smartest people I knew recommended it to me, so my issues might not register, but there were a few experiences going through the tutorials that made me wary I was sinking costs into it relative to my use case, e.g. I have 1 week to build a PoC Flask app with a graph on the back end, and then scale it if the customer cares. That's what I used Neo for, and didn't use dgraph for, even though I figured I'd hire developers to rewrite it for dgraph if it got off the ground.
Anyway, long way round, but I'm a long time believer and user of graph techs and want everyone in that market to succeed.