In Search of… a Graph DB
The Canonical Debate Lab is getting ready to build our unified system, currently called simply enough "The Canonical Debate". Given the highly graph-like nature of debates, using a graph DB seems like an obvious choice.
Unfortunately, our current members have only limited experience with this type of data store. So we're reaching out to the larger community to ask for help in making this rather critical decision before we dive head-first into the unknown.
Criteria
Here are some of our concerns with regards to making this choice:
- Open-source friendly — we're an open source project, without funding, so it has to be free to use, and as cheap as possible to run
- Supportable — we don't want to have to keep our eye on the servers every moment to make sure it hasn't crashed. Unless someone wants to volunteer, we'd rather not have to figure out exactly the right way to tune the JVM, the memory, the number of threads, the memory per thread, the GC algorithm, the…
- Versioned — one of our goals is to allow users to audit/trace the changes over time in the graph. This means being able to see what the debate was like, say, 3 days ago, or before someone made a certain change. We can do this via application programming, but the more native support, the better.
- Edges as nodes — this is also a bit optional, but would help. In playing with ArangoDB, we learned that edges could themselves be treated as vertices, which matches perfectly with our model of Arguments as edges that can be attacked or supported by other Arguments. Unfortunately, the web visualizations do not seem to be able to handle showing these relationships, at least out of the box. Not a deal breaker, but not perfect.
- Directed cyclic graph — although we'd like to pretend debates will not end up going in circles, we know this will happen. Arguments are directed edges, but we can't prevent people from pointing them wherever they believe necessary.
- Reactive API — also a nice-to-have, but also one strongly requested by our front-end developers, who would like to create some "real-time" interfaces straight from the data layer.
- Golang and/or NodeJS-compatible — we haven't actually decided on our final backend developing language (maybe something for another post?), but it's likely to be one of those two.
- Blockchain-compatible — ok, now I'm just swinging for the stands here. But the truth is that one of our long-term goals is to make this platform be fully trusted, transparent and censorship-proof. This currently means involving blockchain solutions, but we're open to discussion.
Our Short List
I honestly don't know exactly how this list was compiled, but we're currently looking at the following options:
We'd love to hear from experts in one or more of those technologies to know what you think. In fact, in my experience, this kind of decision is often made by someone on the team that happens to be a wizard in the option chosen.
Casting Call
So… if you happen to be good at one of the technologies above (or another graph DB tech we didn't mention), please contact me below, via Twitter, or join us in our Slack Team!
