peat dot org

Almost all of the apps I build rely heavily on graphs — not pretty charts, but rather networks of people, places, things, or concepts that relate to each other in different ways. I’ve been looking for alternatives to standard table oriented relational databases, and the most interesting project I’ve found so far is Neo4J.

The concept behind Neo4J is simple, and it’s relatively easy to get started with if you’re comfortable with Java. The basic semantic concepts you work with are nodes, relationships, and properties. For example, Peat (node) is friends (relationship) with Howard (node). Nodes and relationships both support freeform key:value properties, so I could set a birthday on the Howard node, or a note about how we met on the Friend relationship. Very simple and flexible.

The real power in Neo4J is in it’s traversal system — complex graphs are pretty useless without being able to pull information out of them, and SQL based systems pretty much suck at handling complex queries through nested or recursive structures. Neo4J’s “traversers” are much simpler to build, and feel pretty darned quick.

What I’m really enjoying is the simplicity of the system. The API only describes 12 classes, and there’s only 3 or 4 you need to be familiar with. The jar file weighs in at under half a meg. The “hello world” example is readable straight out of the gate. There’s even a command line shell for exploring your data. Simple concepts. Easy to learn. Small foot print.

Pretty cool stuff.

If your work involves designing and building systems that rely heavily on relationships, Neo4J is definitely worth checking out. Caveats? As of May 13th, it’s still in beta — but it looks like the 1.0 release is around the corner.

Here’s an interesting excerpt from Werner Vogels’ Dynamo paper about some of the guts behind Amazon’s e-commerce platform:

“For example a page request to one of the e-commerce sites typically requires the rendering engine to construct its response by sending requests to over 150 services. These services often have multiple dependencies, which frequently are other services, and as such it is not uncommon for the call graph of an application to have more than one level.”

There’s no doubt Amazon uses extensive caching to keep performance up, but 150+ service calls to render a page is remarkable, regardless of how you cut it. Even more impressive is how all of these services are built around the assumption that something, somewhere is failing: disks are crashing, networks are flapping, and processes are dying.

Check out the paper for more details.

Update:  It looks like Ars Technica got interested and put together a little write up on Dynamo.

Back in the days when I was a Java developer, there was a really hot meme called “dependency injection” (also known in some circles as “inversion of control”). The hype was oriented around the Spring framework, which promised to be the next hotness for developing web apps (amongst other things). It’s still around, and doing quite well, but I was seduced by Ruby on Rails before I could really sink my teeth into Spring.

Why am I rambling about this now? Last night when I was trying to fall asleep, Spring floated through my head and I wondered if there was a similar framework for Ruby. Lo and behold, it turns out Jamis Buck constructed a container back in the days before Rails became the web’s darling framework.

It’s called Copland, and this one example is enough to make me keep thinking about it …