I made a demo UI for exploring dgraph databases based on a thought experiment.
The principle was to make a UI primarily based on the new type system that would feel familiar to users of relational databases but also expose the fact that relationships are first class.
Any thoughts?
https:/uploads/dgraph/original/2X/2/2da2e0743c404e513d6308b59bd641e5f0223431.webm
Feels very nice! do you have it open source?
Not yet, but I would be happy to if there’s interest.
At the moment the code is very messy. I just wanted to see how it would feel.
Seems nice! Good job
This is pretty cute and fun to watch.
I’m a bit worried that table layouts won’t scale well for large complex datasets but in practice developers would want to inspect test data only. Which is fairly small and simple, so that shouldn’t be an issue
Thanks for the feedback, Paul. I have the same concern. I will experiment with it further with larger and more complex databases and let you know how it goes.
It looks very nice. The recursive explorer reminds me of the graphql± syntax 
…
Thinking about this I have the following idea.
Let assume that there is a starting node-type in a relative complex graph with many edge-types and much more predicates and you want to find some connection between the root node and the searched predicate. Some times the searched predicate is many hoops away, so exploring the graph from the root node can be very time consuming. On the other side, if you have found the right path, then you would be interested in filtering on some predicates and showing others.
Here I have an example for a relative simple graph based on airbnb listings:
Search for a predicate and path to root node
In this case you would have the user node-type as root node. Let say, you are searching for some information about “price” and you want to “connect” this to user node-type. If you have a well named schema, then you could maybe extract the paths and create a meta graph for the connections.
If the data model has many, many, many node types and predicates (with similar names), then a data dictionary (also modeled in dgraph) could help. The data dictionary would have nodes describing the note-types and edges to other node-types and other nodes representing the real predicates.
So when you search for a predicate, then you could first query the “meta graph” and use this to draw the graph in the image. In the mata-graph you could also model some additional information about the entity (node-type) like description etc.
Query builder
Once you know the paths, you can start exploring your data. You start with the root node and add edges and node-types until you reach the node-type with the desired predicate. The meta graph shows you the way. During this you can set also filters.
Results
Using the normalize directive in the query there should be not difficult to extract the data from the query and create a html table. Using pagination you can browse the result. If the result is OK, then you can go further and use server side solutions for analytics like python-pandas (datatables). For analytics purposes you could also create a in-memoty table and connect it to some data analytics solution.
How do you find the idea?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
