Decentralized Graph Databases: Optimizing Relationships with Intermediate Nodes

Photo by Kevin Ku on Unsplash

First things first. A random image, so the page doesn’t look so boring.

Now :) I have recently been getting into this open source project called gunDB. It is a really cool decentralized graph database, that allow peer-to-peer streaming of data.

Because of this, I have been thinking about establishing some best practices when working with such databases. While this endeavor is primarily for my benefit, I though I would share it so that others might benefit, or perhaps just provide some food for thought… — after all, I’m just a passionate enthusiast trying to make sense of it all!

Over the coming weeks I plan on publishing a couple of stories with whatever insights I discover. 🕵️ I’d love your company, hit that follow button and all that jazz 🎷, otherwise — happy reading!

OKAY ! Now that the disclaimers are out of the way — let’s dive in!

Very quickly about gun

If the words node, edge, graph database or perhaps even gunDB is something you are familiar with, feel free to skip ahead… Otherwise I think it would be handy, to just do a speed run of what gun and graph databases are.

Normally you might image a database like a big table or spread-sheet with a bunch of data in it. What we are talking about here is a bit different. In Gun data is structured in nodes that are linked together.

Example time:
Imagine modeling car dealerships (because cars are the go-to example 🚗). You’d have a list of companies, each with details about their facilities, staff, and the cars they stock. Each car node might carry information about its seat count and motor size.

In a graph database each company, facility, staff, and car becomes a separate node, interconnected for easy reference. The nodes could then reference each other. Your car node would have an ID, say “car001” and then the car-dealer could reference the car by that ID.

Graph databases, like Gun, thrive on flexible node navigation. A well-structured setup enhances usability. A bad structure will be hard to work with. The main idea of graph databases is that you can jump around between the different nodes.

here’s how jumping between nodes might look in gun. Each .get is jumping to a new node. I just wanted to give you an idea, but don’t worry if some of the syntax does not make sense

// log out all car models of all car dealers
// (map iterates over all the different nodes)
gun.get("car-dealers").map().get("stocked-cars").map().
  get("model").on(value => console.log(value));

Read more about gun and graph databases here.

Principle: Using intermediate nodes in one-to-many relationships

If you are just here for the principle I will provide it here. Brace yourself, it’s a bit mathy, but hey, that’s how I think principles deserve to be. Apologies if it’s not your cup of tea!

1. If a node A is referenced by two or more nodes N_0 to N_n
2. and the reference to Amay at some point need to be replaced in the nodes N_0 to N_n
3. an additional node A´ (a-prime) should be inserted between N_0 to N_nand A.

Anyhow, it’s probably easiest to show and not tell. I will use some graphs in the explanation below!

Reason and explanation

Let’s explore this with a practical example — a chat application. In this scenario, we have users and chat_rooms. Each user stores their messages in a node called messages, which is referenced on the user node.

For illustration purposes, here’s a glimpse of how this might look in gun. Don’t fret too much about it, if you are not familiar with gun:

// putting a message into the database
user.get("messages").set("hello from user");

//reading the messages
user.get("messages").map().on(message => console.log(message));

Using direct linking: BAD

Now, imagine a database structure where a chat room directly links to the user’s messages node. Picture this: the user’s messages are utilized in multiple chat rooms. If the user decides to clear the message list (deleting all their messages), they face the daunting task of updating the reference to a new message list in ALL CHAT ROOMS where the old one is referenced.

Using direct linking

Using intermediate node: GOOD

Now, envision a situation where the user opts for a different approach by linking to an intermediary node. Updating the value becomes a breeze. The user simply needs to update the reference to the messages list once — on the intermediary node — and voila, it automatically reflects the change everywhere.

So, to recap

Use a lot of intermediate nodes in your graph database structures because they allow you easily update things. You can update the reference to a node, A, on the intermediate node, and it would be like you updated everything that referenced A, all at once!

I hope this principle has made sense to you. I have been skipping over details, and (as always with cherry picked examples) the real projects out there, will be more messy. Let me know what you think!

Thanks for reading along, I hope to see you in another article :)