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).
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.
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.
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.
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 .
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.
