I've been meaning to update this blog with a few things, but I've been too busy on one sprawling project: my SPACE GAME! attempt. I'll write a post about that endeavor some other time. Regardless, it's a project so huge that it's spawned a hundred other projects. That's how you know it's a good one. One of those spawned projects is my need for a graph database. Initially, I looked at OrientDB and Neo4j, and I found them both... bloated.

Also, I hate Java, and anything built in Java. (Or, in the case of Minecraft, I just hate that it was built with Java.) Why do I hate Java? That's another blog post. But long story short: too much bloat. Nine times out of ten, a Java application takes up way too much memory (see: both of those graph databases) and is needlessly complex (see: Neo4j).

I got frustrated with both of those graph databases pretty quickly, so I said to myself, why don't I just build my own? I really only need to keep track of two types of data: nodes and the connections between them. That's really it. The data models are hilariously stupidly simple:

// a node is...
{
    'ID': 1,
    'Name': 'A node!'
}

{
    'ID': 2,
    'Name': 'Another node!'
}

And...

// a connection is...
{
    'ID': 1,
    'Name': '1 to 2',
    'Source': 1,
    'Target': 2
}

Holy shit, that's pretty much the long and short of it. I'm not even kidding.

So I built it in Go, because why not? Every time I come across a project idea like this, my first impulse is to try something brand new. (From this admission, you should be able to deduce that new projects have a terrible recursive development cycle effect: every new project takes 10x longer than it should because I'm learning a new language or paradigm or something.) And I've been reading non-stop gushing reviews of Go on goddamn Hacker News and bullshit like that.

The result is my SIGIL graph and spatial database. I threw spatial information in there (simple X, Y, and Z properties) because I found them useful for why I was building the database in the first place (for a space game). I've already started writing client libraries for PHP and Node.js (because I use those languages a lot). But you don't really need a client -- mostly the clients are just helper functions. The SIGIL database can be accessed easily using REST calls.

Why "SIGIL"? I couldn't figure out a better name, really. It was gonna be CGSDB (Cyle's Graph and Spatial Database) but that's lame. And is it "SIGIL" or "sigil"? Either, I don't care.

One of the important bits here is that I managed to learn Go in under a week. I've learned C, C++, and Obj-C, but Go is much more accessible when you're coming from loosely-typed, holding-your-hand languages like PHP, Javascript, and Ruby. The simple beauty of go run db.go is incredible, along with the package management elegance of go get module/name/here. Amazing work on Google's part for making this language happen. It's exactly what compiled languages have needed for a decade.

But yeah, SIGIL is very simple. It's two arrays: one for nodes, one for connections. And it's a whole lot of REST-accessible helper functions: querying for nodes or connections, getting distances between nodes, getting the shortest path between two nodes, etc. I'm going to continue to evolve it as I discover more features that I need as I develop my game, but for now it's pretty stable (for a first attempt) and fairly usable for my needs.

My next tasks with it are to better implement memory management (even though Go does garbage collection, I can make things more streamlined) and using goroutines. If you have any thoughts, questions, or whatever, about SIGIL, let me know via @cylegage.