That’s great. Now let us cast a datetime scalar as year, month, day, day of week etc. and then we get closer towards useful aggregations and summaries
This is a long thread guys – it would take me a while to read through this and grasp.
Meanwhile, Ask Dgraph Founder Anything.
3 Likes
That is THE question. As a competitor to Hasura / Tigergraph, Dgraph does not support many of the graph algorithms or Cypher, a language which would allow users to plug Dgraph instead of Neo4j.
As a GraphQL system, Dgraph provides facets, transactions, which are not so useful for GraphQL users. For this, Dgraph should aim for Firebase feature compatibility.
This makes me wonder if Dgraph should be forked into two directions – graph DB, where Cypher support is added, perhaps. And GraphQL system, which trades consistency for performance.
4 Likes
I’m not sure if this is a useful suggestion, but I run Firebase’s Firestore in production for a small, nonprofit application. Two well known limitations of Firestore are that it doesn’t support full text search and it doesn’t support relations/joins.
I was just reading Algolia’s docs to see how their search product works and I see it only supports full-text-search. It doesn’t support searching across relationships.
As a side product, it seems possible dgraph could offer an Algolia like SaaS offering that focuses on searching across relationships (and you could throw in the limited full text search capabilities that dgraph already has). Rather than a competitor to Firestore, this dgraph side product would be a compliment to Firestore and other services (I’m focusing on Firestore here because that’s what I’m familiar with, but I expect MongoDB and other products would similarly benefit).
A user could sync documents containing relationships to this new product and then search across those relationships. The user would then receive matched document IDs in the response, which they would use to find the original documents in Firestore (or whatever database they’re using) similar to how Algolia search works.
The primary theoretically difference between this product and dgraph itself is the scale/complexity. There would only be a SaaS offering (presumably built using dgraph the database) and every document uploaded would have all fields fully indexed by default. I imagine you could simplify the security model as well as, perhaps, discard real-time-updates and transactions since Firestore (i.e. the real database) would be providing those features itself and this would just be a serverless search/indexing tool.
It’s possible that this suggestion is basically a suggestion to create dgraph. After all, if Algolia supported relationships it’d basically be a database. But I imagine there’s a lot of features you could skip if you lean into the idea that your product will be a compliment to other products like Firestore. And then over time you could flesh out the features to make the product into a full database.
I say this as someone who tried Dgraph and found it to still be half baked (e.g. the graphql API doesn’t support nested filters but I expected that to have been part of the MVP).
Anyway, this feels like an off-the-wall suggestion but I was just reading the Algolia docs and thinking, “It would be great if there were a product like this for relationships…” Seems like such a product could be built on top of dgraph. Please no “DQL” though.
5 Likes
@thefliik - I have thought in detail about this. As a person who has built a medium-sized project in Firestore, and working on one in DGraph, I can tell you DGraph is more production ready by far than Firestore. I would not say the same thing about MongoDB, which seems to be production ready (even though I now hate noSQL). There are many situations you simply cannot even use increment / decrements in Firestore to use counters. Try building a follower feed with Firestore and Algolia. It is impossible, because neither of them allow joins.
That being said, DGraph is not 100%, but it is 90%. The extra 10% pretty much can be done with work arounds of Custom Lambda Mutations, and Custom DQL Queries. Firestore has no work-arounds.
I would argue to just switch your entire database to DGraph.
You can search on nested relations in DGraph, you just may have to currently build your own DQL Custom Queries.
Everything can be done in DGraph, you just may have to currently do a little bit more work than WHEN DGraph GraphQL gets more features.
Why manage 3 databases (or 2), when you can manage 1.
J
5 Likes
IMHO - I like DQL and instead of Cypher I would say for those of us really into data analytics what I miss most is their graph algorithms library… 
6 Likes
Enterprise Self Hosting should be cheaper and encouraged.(Right now, you are discouraging it). All enterprise customers are not always on AWS.
As the schema grows larger, Dgraph becomes slower.
2 Likes
I was looking for a GraphQL endpoint backed by a graph database and found Dgraph.
Looking at this very long and amazing thread it seems that there are two primary users:
- developers looking for a robust and fast GraphQL endpoint with features that support a great developer experience
- database specialists looking for a robust and fast graph database with features that support a great database management experience
Both of these groups are also looking for:
- a serverless cloud experience
- a self-hosted experience
There are probably a couple of other user categories that would really be interested in Dgraph:
- no-code and low-code developers and platforms accessing a serverless cloud GraphQL endpoint
- UI and UX designers looking for an effortless way to enhance their prototypes - which are getting more and more sophisticated and merging into no-code and low-code solutions
- data analytics researchers
These last two groups are likely to use either Plugins available on their platforms, or go to an integration service like n8n.
What if Dgraph created, evolved and maintained a node designed to make it so easy to integrate with no-code and low-code platforms through another open-source integration platform like n8n?
Is there any reason why Dgraph cannot be a platform for both developers and database specialists?
Another consideration is to build on Dgraph’s developer features to also support a very compelling product for no-code and low-code builders. This kind of service could compete with RMDB based products like Xano:
3 Likes
Hello Nick!
I think dgraph will focus on the two first categories while the no-code low-code will be done by “intermediaries”. Dgraph should probably focus on its DB and its cloud service, the performance and DX, while an intermediary can focus on low-code prototyping and data-analysis
Here is a summary of dgraph key missing features and issues that @jdgamble555 and @amaster507 made:
At Blitz (YC S22) we are actually becoming one of those intermediasries for the other usr categories that you mention (https://www.blitznocode.com/)
We are building an abstraction layer over dgraph so non-developers can create a data model and pair it with workflows and an interface builder. With zero code! (It sounded like an Ad but is just me being hyped about by my own product lol)
So imagine a baby between xano/airtable + n8n/integromat + retool/stackr that a non-tech operations manager or entrepreneur can use to build tools or prototype new features.
I think that’s the right way to go, splitting the different types of customers with different types of products. So each one can focus on delivering the best value to their segment.
We are also developing a graphQL alternative (blitzQL) which works diretly in JSON format instead of strings, where we will be able to filter nodes by children props as well as editing children nodes from their parents, or cascade deletes. Eager to share more about this soon 
3 Likes
Hi Loic,
Nice work 