Over the last week I've been working on the user graph and an accompanying management service for a project of mine. This particular graph does have some complex traversal and cycle requirements. It's not exactly six-degrees of separation being traced, but in some cases it's actually a little more complicated than that. As the case usually happens, I'm working on building something that is much more complex than it will look to the user (isn't that the goal?).
Here is one part of the usage:
That's a demo user view of the connected network graph that is part of the broader application. The relationships here are compound and unique. Where we normally see social media and apps treat personal and love relationships as the cookie cutter image of a "traditional" marriage - the reality is much more dynamic. This is normally represented by some vague addition of "complicated", "open", "private", or other I want something better suited to capture the nuance of the connections across relationships - especially in the ENM, Poly, Swinger, Kink, and Alt communities. A place that is built out from those relationships rather than throwing the occasional work-around for them.
The image above is also just a small slice of the large pie I'm carving up here. Building the graph has to also consider safety, matching, calendar, events manager, and communication channels that use the graph as the backbone of everything. So, again - it's a complicated system. What does all of this have to do with Arango?
As I've turned to the graph structure for users in earnest, I considered several different approaches. I'm early enough in this project that I can try a few things and toss what doesn't fit. So, I decided it was good time to dig into Arango DB a bit and see how it could handle the needs. My top questions revolved around the implementation, management, data-handling, and of course - what does it bring to the table by way of graph traversal.
It's a winner!
At least, that's my current opinions (again, early days - things could change). Like I mentioned, I've only been working on the testing for a bit over a week now. In that week I've started to see the edges of the power available through a good implementation of Arango DB with the correct configuration of edge collections combined with the knowing what to drop in a document instead of an edge collection. The resulting simplicity of working with the data on the application side is incredible.
Here are a couple of typescript functions that I've found extremely helpful in getting my collections created. It's a simple script - but gives me a measure of straight-forward management of the collections at this early stage. I'm sure that will change once I'm working with data that I'm not okay with blowing away 10-times an hour if required.
// Create document collections
for (constcolofdocumentCollections) {constexists = awaitkindredDb.collection(col).exists();if (!exists) {awaitkindredDb.collection(col).create();console.log(`Collection '${col}' created.`); } else {console.log(`Collection '${col}' already exists.`); } }
// Create edge collections
for (constedgeColofedgeCollections) {constcol = kindredDb.collection(edgeCol);constexists = awaitcol.exists();if (!exists) {awaitcol.create({ type: 3 }); // 3 = edge collectionconsole.log(`Edge collection '${edgeCol}' created.`); } else {console.log(`Edge collection '${edgeCol}' already exists.`); } }
I won't be using Arango for everything across the app. That would just add unneeded work to some areas. Still, with Arango and Postgres both handling what they are best at I'm feeling good about the progress.
Anyway, I thought it was worth sharing my current thinking on progress and share first-thoughts on Arango DB. I love learning new tools!