Yeah. When dgraph was born, rust was not yet mature.
I also look forward to the rust version of dgraph, which will bring very good performance and security.
I hope team can consider rust.
Yeah. When dgraph was born, rust was not yet mature.
I’ll let someone from the team answer all your questions. But just want to chime in. If you’re looking for Dgraph’s GraphQL, then you should consider https://dgraph.io/slash-graphql .
Thank you for a reply. Down the road I will definitely consider a managed service!
As of now I am trying to learn as much as I can, to impress interviewers and maybe have a wonderful website along the way while standing on shoulders of giants.
This depends on the resources you have. Personally I never thought of track this, maybe we should start doing this in benchmarks. You can check out this guy bench GitHub - linuxerwang/dgraph-bench: A benchmark program for dgraph. and in our blog we have some benchmarks too Dgraph Blog - Dgraph Blog e.g Loading close to 1M edges/sec into Dgraph - Dgraph Blog
You can also test with ludicrous mode, and you gonna have astonishing results.
For now, GraphQL don’t support Geo-Spatial queries. You can read this RFC Implementing Geo features in GraphQL
Dgraph wasn’t designed for that.
Not sure what is the point of the question. The docs should say what and where? Your example is the answer?
If you are starting to learn Dgraph you should take our Tour A Tour of Dgraph
The only difference is implicit. One is focused on GraphQL only, the other on Dgraph’s features, operations, and so on.
Not possible, you can make the whole server read-only tho.
Not sure If I got the question. Maybe the answer is https://graphql.dgraph.io/dgraph. If not so, please clarify. BTW, as
GraphQL+- is inspired in
GraphQL, almost everything is similar between them.
In general, yes, you should handle this with a storage service. You can use https://graphql.dgraph.io/custom/ to do this.
I think so, it Is hard to find good Go Dev, so imagine how hard it is to find Rust dev. Today maybe it is different.
It is in Ratel’s roadmap to support GraphQL queries.
I do think we can be more clear there. Most users would be happy with GraphQL, and that should become the entry into Dgraph. For advanced users, they would want the power that comes with GraphQL± and transactions and so on. By being clear about these differences, our users can have a better experience.
This might also be a good time to switch the naming to DQL from GraphQL± .
Thank you for taking the time to answer everything.
Never realized a community can respond much faster than manually googling each and every question I had.
After watching your presentation: Dgraph: Journey with GraphQL.
I realized, what GraphQL± is capable of, the motivation behind it, and I am going to use both until all the features of GraphQL± are migrated over to the native spec.
If all the features of GraphQL± are not going to be ported, then I will stick with the superset QL.
I loved the approach and I have nothing against GraphQL±.
It’s just that I was torn between the choices of using ApolloClient and the clients provided by Dgraph.
Between GraphQL playground that can read the schema & supercharged Ratel, that can show the nodes with arrows, update schema on the fly.
It would be awesome if there was a page on the website, that would have a comparison between these two QLs.
A 2 column summary with green/red ticks can point out what’s supported & what’s not in each QL, and if a port is WIP or will never happen.
If both the query methods are going to be present, i.e. one for beginners & the other for advanced, then I can use both.
If one is going to be a superset of the other, then I am all in for DQL!
P.S. The website didn’t allow me to post consecutive replies, even though I was replying to above post!
Agreed. We need a page about that. @michaelcompton: Can we start with a discuss topic perhaps which explains the differences? And then convert that over to docs.
That’s by design. You can select what you want to reply, and quote that to reply (like I’m doing right now).
Thanks for the prompt action.
I was a noob in the ways of how all these works!
Thank you for the tip.
Hi, I am Anthony from Oklahoma, USA. I am the developer of a new startup focused on assisting religous organizations. We launched a version of our SAAS Feb 2018, but are in the process of rebranding, refocusing, and rebuilding from the ground up.
We have been using GraphQL for a few months now backed by RDS and are getting tired of working around the limitation of a relational database driving a graph presentation of that data. Trying to decide which graph storage engine best fits our needs between dgraph and neo4j (4.0).
I am at a cross roads with ACL though as we want more granular control over properties and relationships like exists in neo4j but we see great things in the dgraph realm offering a quicker API build.
I have thought about putting a public GraphQL layer in front of a private GraphQL layer served by Dgraph. Has anyone done this for more refined ACL at a user level?
Here are some use cases we want to accomplish:
- restrict access to object properties depending on user role.
- restrict access to relationships between objects while allowing a user to still see both objects individually.
- restrict objects based upon user role (Dgraph can do this)
- specifically grant read access to only certain object properties based upon user role
- grant write access to only specific object properties based upon user role. (Neo4j still is lacking this too)
- grant read/write access to an object while restricting delete.
Also, there is also a typo on Hello World | Basic | Dgraph Tour
A UID is not an edge, but can it be returned in a query with
It should be “but it can be”
Welcome to this community, @amaster507.
Have you looked at the auth documents for GraphQL. They provide pretty granular auth.
Thx @mrjn, I believe that is exactly what I was looking for just hadn’t made it to that part of the docs yet. There is a lot of new material here to cover. Thank you to everyone for all of the hard work and expertise.
Excited to utilize dGraph! Didn’t join in June but I definitely still feel new…so much to learn!
- Does an example of query cost for /graphql exist somewhere?
- Is there any difference in functionality between dGraph Clients?
- Do you have a preference for a given client for any reason at all?
- How does /graphql affect the way an application/api layer interacts with dGraph?
- Will dGraph share point-in-time snapshots of systems utilizing /graphql? Data is the resource of the 21st century and makes this critical.
Cool technology! I find the documentation helpful but it is like drinking from a firehose – I often find it difficult to make design decisions around what’s available. This type of documentation paired with query cost (/graphql) examples would help me (and many other startups) get off the ground, fast.
I don’t think so, but I gonna ask someone about the whole picture.
They shouldn’t. If you see something you can fill up an issue in their respectively repo. All clients should follows Dgraph closely.
None, Dgraph’s GraphQL feature don’t touch anything else. It is independent. But if you gonna use GraphQL and wanna have an API your API should follow the graph structure that the GraphQL feature will create.
Not sure the question. Is it related to GraphQL for sure? can you share a link with context? If you are talking about point in time recovery (back-ups in general) it is EE feature. I think it is coming or it is already available, need to check.
Hi June-Joiners and Dgraph community,
This thread is a very nice idea, thanks for welcoming us!
I have joined the Dgraph forum because I am currently developing a Spark Dgraph connector that allows to read data from your Dgraph cluster into your Spark cluster. For this I hit a lot of mainly performance questions that I will post separately over the coming days. Watch this place!
Here I want to say that I am impressed by what I have seen so far. The cluster setup and endpoints are pretty neat, very easy to get up and running, and the community and developer team are pretty active and responsive.
Keep on with the good work,
Hi @EnricoMi, Welcome to the Dgraph community. We are glad that you liked our services and community support and thank you for your review. Feel free to reach out to us whenever you face any issue.
By query cost I am assuming you refer to the execution plan in relational databases ? Because in this sense then I believe what we would be asking dgraph is can u tell me the path taken to solve the specific query .
Both this question and the one immediately before are referring to the new Slash GraphQL SaaS offering (managed dgraph service).
Please find relevant links below:
if the point was about literally the “cost to run a query in Dgraph” in the roadmap there is a feature related to this called “Query Planner”. But not sure how this gonna work on GraphQl feature. As it is still an idea, there is not much to talk about.
just read about dgraph yesterday ( altho i’ve seen the website since a year ago i think, and i thought it was going to be “justanotherdbtryingtosurvivethiscruelworld” ).
But apparently i kinda fell in love with the concept after watching one of the presentation on Youtube.
Hey everybody! I’m a DevOps engineer enthusiastic about Open Source and Video Games. I work at Katharos Technology where we work on both!
I found Dgraph yesterday and am loving it so far. I think the idea and the ease of use is amazing for GraphQL. I’ve got some concerns about the licensing that I’ve voiced in another topic, but I love the Dgraph Core Values and it seems like you guys are doing some awesome work.