I don’t remember, but I think it was 90% fixed. The problem is that you have to have an extra block(that’s why I mentioned the “loop solution”). And also I think you have to do it 1root:1root - You can have many nested, but it can break(I think, I don’t remember) the query. Need to check. But is partially fixed as far as I remember.
2 Likes
As a side note: DARPA projects are probably a good way to get funding to expand DGraph, as the technologies really apply to a lot of emerging hard problems.
3 Likes
Hello there! As a newcomer, my 5 cents:
-
Documentation / quick start are OK but not perfect yet! It took me long time to understand basic stuff like the difference between GQL and DQL. The differences and usage of the apis to control data and control backend also are not really clear, at least got me confused. Another point that I’m still completely clueless is lambdas. I would love to have some field as “calculated” values that depend on other fields, but I can’t find a way to do this.
-
Dgraph cloud: I tend to skip every initial tutorial of every platform/tool, I find them really annoying. The first time i got into the Dgraph cloud, tho, i would have loved having somebody explaining to me what are each one of the elements in the menu. I’m still a bit confused after 2-3 days
-
Feature request: This is my personal wishlist so far
- native timestaps and timerange
- Nested filters and updates
- cascade operations
- @auth at field level in addition to having them at a type level
- pre hooks & post hooks: not sure if this is doable with lambdas, as I still did not get how they work
-
Bugs: This one is driving me crazy. In chrome (W10), each time that i want to paste something into the schema or the GraphQL editor a menu pops in… CTRL + V just opens the menu with the types. If i already set up the type, then it just does not do anything. So each time i have to write a first type (f.i. query), use the mouse to paste all the data, and clean the file. The only point of real frustration i’ve faced so far!
-
Marketing: I agree with most of the comments about your com. It is not clear. You may need some help from a marketing guy, but my intuition says you have to market yourselves as the firebase killers or a supabase with technology of this century. So answering if dgraph must be a DB or not… first step in my mind is continue being an amazing DB and fix some key missing features. The second step is to become a full BaaS to help devs build apps and MVPs faster.
-
Dgraph is amazing, I’ve fallen here by chance and it seems i will use it for as many projects as I can
5 Likes
Hi, Any plan to include some authorization/authentication system into dgraph?..I’m using supabase and it works fantastic, this provides a sweet authentication system and I don’t need use external (and expensive) services or run my own auth server
I love graphs db’s, dgraph was love at first sight (I come from using neo4j and more experimental db like titan db…I think it was discontinued) but I really find overcomplicated to use an auth services when supabase gives me a whole package with the serverless philosophy
thank you so much for create Dgraph
1 Like
Dgraph already have the ACL and Auth feature(this one in the GraphQL part). There’s no plan to add Auth in the DQL part for now.
Firebase Auth is free and pretty easy to get going:
Scroll down to see the standard claims version, which is much easier to implement.
J
1 Like
Dgraph uses JWT auth. I’m using https://magic.link to log users in, then I generate a JWT serverside and hand it back to the user. The JWT authorises the GraphQL requests coming from their client (browser). I posted some example code in Discord you can search for.
Agree that Dgraph ideally needs a Supabase-like UI for quickly configuring and verifying auth rules. Would speed up Dev time a lot
1 Like
As a followup to my suggestions mostly around the topic of providing much more robust search capabilities much like ElasticSearch I recently discovered https://github.com/prabhatsharma/zinc
Zinc is a search engine that does full text indexing. It is a lightweight alternative to elasticsearch and runs in less than 100 MB of RAM. It uses bluge as the underlying indexing library.
Seems like a great fit for Dgraph!
5 Likes
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.
- Also collections probably? more json focus ? multi model like feel?
- Schemas are good but currently, dgraph is for rapid iterations so more focus on schemaless dev?
-
expandto work without schema - tools to gen txn that move data when schema is modified
- multiple databases in single backend?
- typescript binding for dql client as well so responses are typed?
- customisable full text
- ability to add custom indexes
- pregel like compute system (with some common targets already implemented)
- rewrite in rust to brag on performance (just a rust fan boi pls don’t kill me)
- OLAP mode / integration with olap tools
1 Like
I find this ironic. Dgraph brought GraphQL into the core because of the users demand for it. Go back and read old github issues, etc. This was done by bringing Michael Compton (and others) into Dgraph who had built exactly what you are referring to now outside of Dgraph. And now 2 years later users ask for this to go away back into the host it yourself graphql that connects to DQL.
I don’t believe this is the right direction but there is value here to your point. With other databases you can swap out the engine. What if dgraph handled GraphQL and other future languages such as Gremlin like extensions that could be added into the core?
This way a user who doesn’t want GraphQL doesn’t even get any of those endpoint because they didn’t install the GraphQL extension but they want Gremlin so they install that extension. And this I believe would open it up for more and more extensions to be added such as Graph Algorithms, or Cypher, or GQL (looks like it is becoming official spec)
Dgraph supports namespaces now.
I don’t think GraphQL is going anywhere. I just think it is for advanced real users. That being said, the trend has always been, and will always be, quick development with the least amount of effort (so we can concentrate on the product).
I believe that is why things like Supabase and Firebase are popular (and why they got backers). They work out-of-the-box with little to no knowledge and configuration. This is always the future.
That being said, they work on SQL and noSQL databases, not Graph. Whether or not it is DGraph, Graph Databases will catch on as the most powerful and intuitive, as soon as someone makes them easy and stream-lined.
DGraph is 80% of the way there, but needs to tighten up some things like the @auth directive, search features, and nested data relationships (filters, updates, and deletes).
That being said, we don’t know anything about the direction of DGraph, because there is unequivocally no communication from anyone about this. Hopefully it is the right direction for both our frontend developers, and our backend primary graph database users.
J
3 Likes
I do remember the time when it was added. You are right about that users asked for it but at least I wasn’t the one asking.
Maybe what users didn’t expect is that it with such a tight integration it would become claustrophobic.
I guess we should not listen to solutions proposed by users but only the problems they are facing.
That’s why I said I shouldn’t be giving out solutions but it was just faster that way. I could list the problems instead of solutions if you want.
@jdgamble555
Graphql may stick, and I would like it to but it’s certainly not fit in every situation and not the majority of developer. It’s a team thing so there’s high barrier of entry for graphql into stacks.
As you said graphql is loved only by advanced users and advanced users are much more likely to trade full freedom in customisation over magic that does things for them.
So tight integration of graphql serving might be hampering acceptance of dgraph. I don’t really know. You probably need a survey or something.
The majority of developers probably use a rest api, which graphql is a huge improvement on if you have relational data (especially with local caching etc).
I didn’t say only advanced users. In fact, I would say most real advanced users will write their own custom middleware (so quite the opposite), although one part of this middleware is probably in GraphQL.
This is just my opinion, but I don’t see how. You can easily use DQL without DGraph GraphQL. I think the majority of DGraph’s users don’t use the GraphQL middleware, but I have no idea as far as DGraph Cloud users, the paying users.
That being said, the product they’re selling is not solely a Graph Database. I agree with @CosmicPangolin1 that if they can’t support two eco-systems, they need to choose.
The people that use GraphQL don’t really care about GraphQL in-and-of-itself. They care about the middleware, which most DbaaS do NOT provide outside of the box (I spoke about this somewhere on here). GraphQL allows for caching on the front end, and is made for querying graph data.
Either way, the most important thing is that it is too costly to start all over at this point. They are 80% of the way there with GraphQL (it is probably impossible to get to 100%, but a few features we have listed can go a long way).
J
1 Like
There’s some misunderstanding here. By graphql I mean the original graphql spec. I use the term “graphql serving” for dgraph’s graphql.
The original topic of discussion was “what’s lacking” and not “what should we do”. I am just listing what I felt was lacking. I used “maybe” everywhere to make it clear that it’s just an idea in the air, I don’t really know about what direction should be taken.
No worries.
This was Manish’s original quote that started this thread. Without his input or any other Dgraph team member’s input, we are pretty much talking to ourselves for a month now. A lot of these topics, we just plain don’t have the information to understand.
I’m assuming the let's here is the inclusive we?
Perhaps we can actually get some input from the DGraph Team, or the Founder…?
Or at least a Roadmap…? News…? Updates…?
At the very least communication on when the next communication will be, lol (end of 2021) ?
“The single biggest problem in communication is the illusion that it has taken place.” - George Bernard Shaw
J
Sorry, I’ve been absent here – This thread blew up way more than I ever imagined. Clearly shows how much love there is for Dgraph in the community.
I’m working on a couple of blog posts for the release – once I publish at least one, I’ll read through this thread and opine.
11 Likes
Related: can we get @groupby(MONTH(creation_date))
see here: How to groupby date - #19 by geoyws
or here: Suggestions to Improve GroupBy - #6 by MichelDiz
1 Like
Just for reference this would be contingent on first having a month function for datetime. See Related Request:
Exactly! the MONTH part was just an example for all kinds of datetime functions. Others are obviously: DAY, YEAR, HOUR. Just to make it possible to filter, group, and aggregate based on datetime.
FYK we already support group by scalar feat(DQL): @groupby on scalar fields and count duplicate by minhaj-shakeel · Pull Request #7746 · dgraph-io/dgraph · GitHub