Getting Started With Dgraph and GraphQL+
ardanlabs.com
ardanlabs.com
Also, looks like the actual article about "Designing GraphQL schemas" got removed from the front page. It was in the top 10 just few minutes ago.
2. Have the issue like these around regex given any attention yet: https://github.com/dgraph-io/dgraph/issues/5131
3. How to find all inbound outbound edges: The issue discussed here: https://discuss.dgraph.io/t/find-all-inbound-outbound-edges/...
4. How does one backup/restore in a non-enterprise edition? Edit: 5. When will it support multi-tenancy?
1. Yeah, you can run full-text search across multiple predicates, and then if you have reverse indices set up, you can chase their "parents".
2. We're investigating it.
3. You can find all the outbound edges, yes. But, you can't find all the inbound edges, without scanning over the entire DB which we don't recommend for performance reasons. However, if you have reverse indices, you could find inbound edges.
4. You can use /export endpoint [1] and then use live/bulk loader to reimport. That's the equivalent of backup/restore in Open Source version.
1) What extra utility does it provide over other DBMSes with graph abstractions?
2) Is the join-depth problem an actual thing?[0] Does Dgraph solve some real-world problems for you for complex queries?
3) Are there 'pure' graph database systems out there that compete with Dgraph?
[0] https://dgraph.io/blog/post/why-google-needed-graph-serving-...
Dgraph is being used by many big and small companies in the wild. Some public examples are Intuit [1] and VMware [2].
1. Graph abstractions all suffer from high fan-out problem. Because all processing of data needs to be done at the abstraction layer, queries which deep traversals or lots of results in intermediate steps end up fetching lots of data repeatedly. This causes query performance to suffer. This is why many performance focused users avoid anything deeper than depth-2 queries with typical DBs / layers.
2. A way to think about this question is: Are data denormalization and duplication actual things? Indeed they are. If the DB did not suffer from join depth performance, these two things wouldn't need to exist.
3. Surely there are.
[1]: https://github.com/intuit/katlas [2]: https://github.com/vmware/purser/blob/master/docs/developers...
It was probably a misstep to criticize Google, as you did in the link in my post. Your ressentiment only highlighted that respected people at Google voted against your technology. It did catch my attention, but it might have burnt some bridges, and left me with a lingering question mark.
I think if you're sincere about adoption of your technology, it has to be couched in clear terms of how it will fulfill business needs, and I'd like to see that. I'm intrigued by this performance gain, but I need a strong argument to help me decide if it's worth the opportunity cost to try Dgraph to make something.
My comments about Google were accurate. I want to avoid saying anymore on that topic, because that's not my point here.
> My comments about Google were accurate.
Accuracy wasn't the issue.
I look forward to seeing where Dgraph goes, and I might give it a try in the future.
I'm guessing the abstraction has now been internalized. Unless the representation and operations underneath have been customized, and provide the same transaction guarantees and parsimony that a native graph database would for graph operations.